Today in a meeting I referenced a 2007 paper by Arjen Lenstra and Benne de Weger on how to break MD5 to abuse vendor software updates.

Here it is again for convenience:

Given the recent insights into the weaknesses of MD5, the bottomline of our work is: MD5 should no longer be used as a hash function for software integrity or code signing purposes. By now, everyone should be aware of this.

The paper also explained why their collisions were different from before.

In December 2004 Dan Kaminsky and Ondrej Mikle, and later Peter Selinger, published similar attacks, based on the Wang-type collisions that require two binary files that differ only in the colliding blocks. To create such files from two executables with different behaviour that yet collide under MD5, each of the two files has to contain both executables in full, somehow using the collision to switch on the one and hide the other.

Our colliding files are based on chosen-prefix collisions. This means that we only have to append a few thousand carefully chosen bytes to each file to reach an MD5 collision. Each file by itself contains only one of the two executables. This is less suspicious.

And we also knew in 2007, in terms of real-world data, that Google could easily show collisions were far more common than one might expect.

Fast forward to today and it is like some people completely missed five years of warnings.

…the collision attacks observed in Flame could have been prevented if Microsoft had stopped employing MD5 sooner.

Whether or not you buy into the big compute-power argument or the attack sophistication argument for Flame (neither of which are well quantified) since 2007 the message has been to stop using MD5 for trust.