All hashes are one way by definition. If they weren't then
there would be no computational advantage to using them as an
index into a collection class for random access.
Hashes are normally one way in the sense that they loose
information: you convert a string of arbitrary length (8*n bits)
to an unsigned integral type (32 or 64 bits). It's impossible
to reliably recover the original string.
What he's really asking for is a cryptographically secure hash;
one in which, given a hashed value, it is computationally
difficult to generate a string which would generate the same
hash value---whether it is the original string or not.
(For example, java.lang.String or g++'s hashing for a string in
their hashmap use the formula h
= 31*h[i-1] + c, h[0]=0,
which is adequat for most hash table use. But given a hashed
value, it is relatively trivial to apply the formula in reverse,
and generate a string which will have that hash value; it's also
relatively simple to generate arbitrary strings with the
targetted hash value. In sum, it isn't cryptographically
secure.)
Might I suggest MD5 which has about half the computational cost of SHA-1.
And is less cryptographically secure.
I'm not sure I really understand his problem, either. One of
the requirements for a password hash is that it require
significant time to compute, so that a brute force approach
isn't feasable. In this case, faster is worse.
In addition to MD5 and the SHA family, of course, most Unix
implementations use a modified DES; for both Linux and OpenBSD,
the sources are available, and I think you can even use the
OpenBSD sources in your own application without risk of
"infection". I doubt that the algorithm is as secure as SHA-1,
however.
