Security team successfully cracks SSL using 200 PS3's and MD5 flaw.

Sat Jan 3 22:04:00 UTC 2009

* Frank Bulk:

> For me the MD5 hashes on file downloads are more valuable to ensure the
> package is accurate to a byte rather than to verify its authenticity or
> integrity.

Indeed.  I've experienced that first-hand: the hashes helped to
isolate a case of faulty router memory at the ISP I used at home.

(The TCP checksum is very weak and does not detect bit errors which
occur at multiples of 16 bits.  If the probability of such errors is
so high that two of them occur in a single segment, they very likely
cancel out, which was exactly what I observed in the issue mentioned
above.)

> Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost
> complete confidence that the file is the original one?  I don't think anyone
> has been able to create a duplicate file that generates the same SHA-1 *and*
> MD5 hashes as the original file.

For most applications, it's better to include a totally random string
at the beginning of the message, before signing it, and strip it upon
signature verification (or encode it in a way so that it is simply
ignored by the application).  The convergent property of hash
functions (if, by chance, two people come up independently with the
same document, it hashes to the same value) is rarely needed.  A
random string near the beginning means that the attacker doesn't know
the initial internal state of the hash function when the collision is
constructed, which should make attacks involving evil twins much, much
harder.

I expect that at a not too distant point in the future (say, within
the next ten years), strong hashes keyed in a such a way offer very
significant performance gains over non-keyed, but still strong hashes,
so that most protocols which do not rely on the convergence property
will switch to them.  Convergence might even turn out to be too
costly, not just in terms of performance, but in security.  (And I
write this as a frequent Git user. 8-/)