On Tue, Aug 24, 2004 at 10:40:45PM +0200, Almut Behrens wrote: > > for password schemes, it is important that the hash function used is > > one-way: if one knows the password, it must be very simple/easy to compute > > the hash of that password, but if someone obtained the hash of a password, > > it must be very difficult to find something, say z, so that hash(z) equals > > the hash of the password. > > but that's property 1 then (i.e. collision resistance), isn't it? The one-way property of our hash function makes it difficult to *compute* a valid hash input (password) for a given hash output (password hash). If it was not one-way, you could apply the inverse of the hash function to the hash output to yield the hash input. If it would be easy to find collisions, you could construct a *new* hash input for a given hash output. > And that's essentially what I was trying to point out, as I don't think > that, WRT password verification, you'll ever need to know the original x. > It's completely sufficient to find some other password y, z, or > whatever, such that > > hash(some_password) == stored_hash > > where the stored/given hash has originally been computed as hash(x). You are right - you are referring to the finding of "some other password[s]". But if your hash function is pretty good in respect to collision-resistance but is not one-way (being similar to a 1:1 mapping between hash input and hash output), you could simply apply the inverse function to your hash output and are already done. Thanks, Moritz
Attachment:
pgpYrJ0ydOOvt.pgp
Description: PGP signature