Hi! On Thu, Feb 12, 2009 at 03:59:20PM +0000, Christian Weisgerber wrote: >Hannah Schroeter <[email protected]> wrote:
>> However, I don't see it as *so very* critical. The practical attacks >> against MD5 are birthday attacks, not preimages for a given hash. >> At least not yet. >Actually, if you can overwrite or append a chunk of data, you can >create an MD5 collision at will. This allows for some practical >attacks. >In particular, arbitrary data can be appended to a gzipped file; >gzip will just ignore it on extraction. >In combination this means that creating a modified gzipped file >that shares the MD5 hash and the size of the original is quite >achievable. Ok, I was unaware that you can also, practically feasably, create collisions for *given* hash values (which would be an attack against the MD5 files of OpenBSD, for example, when someone checks the MD5 files from many sources, but downloads the tarballs only from one). What I am aware of is the birthday attacks (choosing some bits of *one* chunk of data someone signs, in parallel crafting another chunk of data with the same MD5 sum you can later substitute, e.g. the recent attack against an SSL CA that still used MD5 for signing certificates). So your scenario is creating a somewhat shorter malicious .tar.gz, and kind of "compensating" for the hash value by varying the appended junk (which is ignored by gzip) - are there already known feasible attacks that do something like that? Would it be too difficult to change the md5 invocation in the release target in /usr/src/etc into sha1 or sha256 (i.e. cksum -a sha256), or just to *add* them there? (And perhaps add creation of a kind of xMD5 file or xSHA... file into /usr/xenocara's Makefile, e.g. in the dist target after maketars and checkflist... That would make checksums work without needing to synchronize base vs. X builds on the build hosts.) Kind regards, Hannah.
