On Mar 6, 2011, at 11:16, Anders F Björklund wrote: > Jeff Johnson wrote: > >> On Mar 6, 2011, at 5:24 AM, Anders F Björklund wrote: >> >>> Ryan Schmidt wrote: >>> >>>> Less important than nagging about ports still using md5 at this point >>>> would be to nag about ports only using a single checksum type for a >>>> distfile. :/ In such a nag, it could be recommended to use sha1 and rmd160. >>> >>> Or just one sha256, but yeah that is what I meant. >>> >>> It would be more useful to add the download size, >>> than to use two separate 160-bit checksum lines ? >> >> (obscure aside) >> I used to believe that the combination of a size+digest >> "no tampering" check was sufficiently stronger than using >> more bits in the digest, or adding a second (and longer) digest. >> >> Turns out that there are many MD5 exploits that do not change >> file size. >> >> But without an explicit "threat model" for downloads, its difficult >> to discuss whether 2 digests is "better" than everything SHA* or >> digest+size as a policy rule for downloading. >> >> In reality the digest is more of an integrity than a security check (imho) >> for downloaders, and even CRC would be gud enuf for integrity (but not >> security) >> checks. > > That's pretty much all that MD5 does now, offer a CRC... > > Just saying that instead of using both sha1 and rmd160, > one could use sha256 and size instead. Like Ports does ? > > i.e. replace md5 with size, and sha1+rmd160 with sha256
Since at least five years, there have been known ways of crafting two different files that have the same size and md5 sum -- creating an md5 collision. See: http://www.mscs.dal.ca/~selinger/md5collision/ md5 is thus insecure and not usable for verifying the integrity of files anymore. The exploit takes into account precise knowledge of how the md5 algorithm works; the same exploit wouldn't work on other algorithms. I don't know of any collision exploits for other algorithms today, but I can't guarantee that there won't any be tomorrow, next year, or in ten years. Since any collision exploit is targeted at a specific checksum algorithm, it would be pretty unlikely, verging on the impossible, for an exploit to simultaneously be able to create collisions in multiple checksum algorithms. That is why MacPorts portfiles should use more than one checksum algorithm for each distfile. MacPorts could be enhanced to allow maintainers to add distfile size to a portfile. I don't think that's a particularly useful thing to do, however, given that people can just use "port distfiles" and "curl -I". (If you're not on a network, get on a network; it's 2011.) I don't think checking the file size has any place in verifying the integrity of the distfile; the checksums already handle that much better. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
