Re: Report of collision-generation with MD5
From: Mohacsi Janos (mohacsi_at_niif.hu)
Date: Thu, 19 Aug 2004 17:40:10 +0200 (CEST) To: Jan Grant <Jan.Grant@bristol.ac.uk>
On Thu, 19 Aug 2004, Jan Grant wrote:
> On Wed, 18 Aug 2004, Brett Glass wrote:
>> At 02:54 PM 8/18/2004, Chris Doherty wrote:
>>> what you can do, if you have a proper attack formula, is find *a* message
>>> that produces *that one hash*. that is, if I have message M which produces
>>> hash H, I can use the attack to find *a* message M' which will also
>>> produce hash H.
>> The thing is, passwords are short and have limited entropy. Chances are,
>> if you find a password that produces the same hash, it's M.
> Details in the paper are few, but I don't think what Chris describes in
> the snippet Brett quotes is what's necessarily happening. That is, for
> any given MD5 initial state, they seem to be saying that they can find
> two related messages that produce the same hash. NOT that they
> necessarily can find a message with the same has as a _given_ message.
> Which I guess means that they can tack two different strings on the end
> of any arbitrary file (since they claim they can attack an arbitrary IV)
> and the resulting two files will also have the same MD5 hash, but that
> won't be the MD5 of the original. The two appended strings are
> effectively random, and differ from each other only in a few bits.
To avoid the possible attack probably we should start adding additional
digest to MD5 e.g. - SHA1. Probably some flexible merthod should be used
as in NetBSD pkgsrc: distinfo files says what kind of hash are available:
digest(1) utity computes according to it and make process does comparison
for each available hash. If any fails it reports.
Multiple hash can mitigate the possibility of attack.
Network Engineer, Research Associate
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"