On Thu, Aug 2, 2012 at 10:18 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
Ok, you've whetted my curiosity. What "doesn't work" in md5? I'm aware of the attacks against it.
There's a lot of stuff out there on the problems with md5 (search "chosen prefix collision")...here's one good one: http://www.mscs.dal.ca/~selinger/md5collision/ The (albeit far fetched) attack here is that someone could hack the boost.cowic.de server, replace the file with another boost_1_51_0_beta1_rc1.* that has something malicious in it. Usually if a user checked the md5 of it, then they would be able to see that someone had replaced the file that you vouched for with a malicious one. However, because md5 is broken, it would be easy for the attacker to add padding somewhere in the file so that the final md5 that they generate matches the md5 that you published. I don't think this is a realistic attack on a server with the beta/rc builds. For instance, it would be easier to send a fake e-mail with different checksums if you were an attacker here. The real reason I was asking for the sha256 sums was that I'm already using those in my build script (it is the current, top of the line cryptographic hash function) and then I wouldn't have to lift my fingers to type another command. *groan...sooo difficult* If we really did want to secure things (like when we push the official stuff to sourceforge) the thing to do would be to make a file (SHA256SUMS) with all the hashes for the various builds (.zip, .7z, .tar.gz, .tar.bz2) in it. Then make a second file (SHA256SUMS.gpg) that contains the signature for the first file, signed by the build maintainer's GPG key. This way if the sourceforge account should ever be breached, we'll know if the files up there were the ones the build maintainer actually published. Or we could just keep going as is, I don't think this is a very high-risk project. Tom