[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MD5 collisions found - alternative?

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.


Attachment: pgpYrJ0ydOOvt.pgp
Description: PGP signature

Reply to: