MD5 Collisions...

[Josh Paetzel]

On Tuesday 04 December 2007 08:27:54 am Roger Marquis wrote:
> Colin Percival wrote:
> >> 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.
> >> "
> >
> > I fail to see how the man page is incorrect here.  What do you think it
> > should be saying instead?
>
> I would drop the statement altogether since it is not accurate for MD5
> signatures of binary packages and tarballs.  At the very least define the
> specific scenarios under which MD5 can be broken and drop the "its security
> is in some doubt" claim.  Vague statements about crypto are worse than none
> at all.

I think some of the concerns expressed here seem to be focused on one 
particular use case of MD5.  The main place FreeBSD seems to use MD5's is in 
verifying tarballs for ports.  In this particular application MD5 + checking 
the length of the file + SHA256 is more than enough to ensure that the 
tarball hasn't been tampered with.  In all reality, MD5 alone is enough for 
most cases, since generating meaningful collisions so far has required 
control of the original as well.

If you wanted to get really picky, MD5-ing a file is really the wrong way to 
go about it in the first place, since there's no stopping an attacker from 
replacing the tarball AND the MD5 sum on the download site together....as a 
port maintainer when I update a port how do I really know the files the 
project has published are what they intended?  Unless they are digitally 
signed I really don't.

At any rate, there is some doubt about MD5.  Since collisions have been 
discovered you can't make assertions about further problems being found in 
it.  Perhaps someday someone will find a way to generate arbitrary 
same-length meaningful collisions...who's to know.

-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20071204/e6ba11e0/attachment.pgp