Slashdot Mirror
More MD5 Attacks Devised
rbarreira writes "Bruce Schneier's blog is reporting on a new paper by Vlastimil Klýma, which summarizes a new method for finding collisions on the MD5 hash algorithm. Furthermore, the first pair of colliding X.509 Certificates has been published by a different team."
...for copy protection of my copyrighted works. This man is doing illegal and immoral things under the DMCA, and should be stopped at once. I am willing to testify in court.
Your statement that MD5 was broken for "any and all" purposes is pretty broad. The bottom line in security is that circumventing a security measure should be more expensive (in terms of money, time, etc.) than the value of what it is trying to protect. If you are trying to protect something that is particularly valuable, then yes, you should go to lengths to ensure that it is adequately protected. On the other hand, if you are trying to protect something that holds no real value, why go to the time and effort?
So you were modded down for it. On this point, I will agree with you. You are entitled to your opinion, and I don't think that you should be squelched for it if your opinion differs from those that have mod points. Others, however, are entitled to post a dissenting opinion, much in the way that I am doing now.
MD5 was broken for any and all purposes before
For long-term cryptographic purposes where no other form of authentication exists, yes.
As a general hashing algorithm, it works just fine.
As a short-lived authentication (probably still good for a period of several days, but for a few minutes, such as a secure website transaction, it still works perfectly well) - No need to rush out and change a few thousand storefronts just because, with luck, massive CPU power, and a week or two of CPU time, a determined cracker can fake a message. And note that I refer to signing the transaction itself, not to certs guaranteeing a site as authentic.
As an adjunct to another semi-private means of authentication (such as a password), no problem.
For checking the integrity of a file transfer - In-transit changes such as a man-in-the-middle attack, no problem. Checking an executable against the known-good hash when you have reason to suspect someone might want to change it, probably not so safe.
Now, that said, if a coder sat down today to implement a secure cryptographic hash in a new project, should they use something better, like SHA-512? Sure! But should everyone scramble to purge all references to MD5 from their existing codebases? For 99% of code out there, I'd say no.
If you can't wait for the dust to settle, use SHA-256.
But if you can, you're best off waiting a few years. This and other recent results will spark a period of frenetic research into new ways of building fast hash functions that don't have these vulnerabilities. I'm sure some great stuff will come out of it. A front-runner may not really emerge for a good few years.
I'm in some ways even more struck by Kelsey and Schneier's recent second-preimage finding attack, which works against pretty much all modern hash functions, and suggests that the fundamental Merkle-Damgard paradigm by which we build them needs to be revisited. Our hash functions may end up looking more like Panama than like MD4.
Xenu loves you!