MD5 Collisions...

[Rich Murphey]

Here's a paper by Eric Thompson of AccessData on "MD5 collisions
and the impact on computer forensics" published in the journal
Digital Investigation.  It makes a similar argument that the MD5
collisions have very limited practical impact on current use for
evidence authentication in computer forensics.

http://www.acquisitiondata.com/white_papers/md5-collisions.pdf

Rich Murphey


Iang wrote:
> Norberto Meijome wrote:
>> Hi everyone,
>>
>> Not sure if you've read 
>> http://www.win.tue.nl/hashclash/SoftIntCodeSign/ .
>>
>> should some kind of advisory be sent to advise people not to rely 
>> solely on MD5 checksums? Maybe an update to the man page is due ? :
>
>
> my 2c worth:
>
> The attack is somewhat subtle, and doesn't really apply to the use 
> that is currently made of MD5.
>
> The attack with MD5 is that if you can create your own text, you can 
> create 2 texts with the same MD5.  That however is very different to 
> you creating a new text with the same MD5 as my text.  It is the 
> latter that is normal usage.
>
> In this case, if you are distributing your code with an MD5 signature 
> so others can check it, it is still not a useful attack.  MD5 is still 
> good for that.
>
> Having said that, the general warning is more or less correct; move to 
> a longer hash, if designing new apps.
>
> However, it gets messier, as you need to chose a replacement:
>
>  * SHA1 is good "for now", but expected to suffer in a few short 
> years.  No point in picking that.
>
>  * SHA256 and friends are also under some sort of skeptical cloud, 
> although they are likely good for a lot longer (ask 3 cryptographers 
> for 7 different answers here).  While it could be good to pick SHA256, 
> etc, there isn't that total 100% theoretical pareto-complete 
> confidence that cryptographers insist on...
>
>  * To address this, NIST just a couple of months back announced a SHA3 
> competition.  This will in the space of maybe 4-6 years announce a new 
> generation hash.  Can you wait for that?
>
> There are then a handful of strategies that might help:
>
> a.  switch to SHA256 now, and then SHA3 in 5 years time.
> b.  limp along on MD5 and plan on SHA3 when it is available.
> c.  add "hash agility" to all programs and allow apps to follow their 
> desires.
>
> Which you follow depends on where you are in the crypto-paranoia curve.
>
> Unless the app is an actual vector of validated attacks, I'd suggest 
> b.  If you are part of the community and like inflicting crypto 
> turmoil on your users for fun and pleasure, do c.  If you are some big 
> company and have to answer to others' ideas of compliance, do a.
>
>
>
>> "     MD5 has not yet (2001-09-03) been broken, but sufficient 
>> attacks have
>>      been made that its security is in some doubt.  The attacks on 
>> MD5 are in
>>      the nature of finding ``collisions'' -- that is, multiple inputs 
>> which
>>      hash to the same value; it is still unlikely for an attacker to 
>> be able
>>      to determine the exact original input given a hash value.
>> "
>
>
> That's fine as a description of the problem.  What it lacks is any 
> advice as to what an application developer should do about it.  A 
> tough issue :)
>
> iang
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to 
> "freebsd-security-unsubscribe at freebsd.org"
>