More MD5 Attacks Devised 25
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."
Misspelled surname. (Score:3, Informative)
My bad (Score:1)
But I use MD5... (Score:4, Insightful)
MD5 attacks (Score:2, Funny)
Those attacks on MD5 must be stopped! How can people be so heartless?
Re:But I use MD5... (Score:2, Funny)
He just showed that MD5 has become weak for today's computation power (or his brain power).
Too bad you use MD5 for your work. But at least he showed that MD5 is weak before anyone do something which could damage your work.
And thus give you time to select another encryption/hashing method to secure your work.
Or would you rather learn that MD5 is weak the painful way?
I told you so (Score:5, Interesting)
I was moderated down heavily for stating that MD5 was broken for any and all purposes before. Now I think I feel at least somewhat vindicated.
There are two problems here... Yes, the break in MD5 (and SHA-1) involved two chosen pre-images, and it was still not computationally easy. But there are two problems with hiding behind those justifications.
The first is that once an analytical wedge has been driven into a crack in the algorithm, it often doesn't take long for that wedge to be wiggled back and forth to make the crack even wider. This demonstrates that the attack is computationally feasible enough for anybody to generate two keys that have matching MD5 signatures. I don't think anybody would've agreed that this would happen this quickly a few months ago.
Secondly, deciding when a certain kind of attack is relevant in a particular situation is not trivial. So, if you can generate two different keys that appear identical, what kinds of interesting attacks can you perform? What assumptions to browsers and other software make about keys that are now broken? Can those assumptions be exploited? This shouldn't make phishing any easier, but what if a phisher manages to be the person who generated the bank's key in the first place?
Having an algorithm that is weaker in some significant way than what everybody expects makes everything very tricky. MD5 (and SHA1) are no longer secure hash algorithms, and should not be treated as such for any purpose at all, regardless of whether or not you think you have the gigantic cranium that can think through all the implications of a particular weakness. You are most likely wrong.
Re:I told you so (Score:2, Insightful)
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 en
Re:I told you so (Score:5, Insightful)
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.
Re:I told you so (Score:2)
If you read the article, it was a few hours of CPU time, not a week.
And I hope you get to live with the consequences of your decision. I still say that people are too dumb to think of all the ways in which something can be exploited. It was hard enough to design the protocols with algorithms that had particular desirable properties. Trying to figure out if they work in some situation when some important property no longer holds true isn't a puzzle I think is worth trying to solve. Best to chuck the hol
Re:WTF? (Score:3, Informative)
http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf [sdu.edu.cn]
I saw this link at the page linked in this
Addendum (Score:1, Interesting)
Re:Addendum (Score:1)
What should we use now? (Score:2)
So there is enough buzz to stop using MD5 in several situations at least.
It's a shame because there are so many great tools that many people have made that are now a few shades away from dust but that's how the security game goes.
I run into situations where I've used MD5 to uniquely ID/fingerprint/tamperproof document images used in legal cases, so although the chances seem very slim that the md5 problems would be exploited in this instance- it's no longer something i can ever use again
Wait for the dust to settle (Score:5, Insightful)
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.
Re:Wait for the dust to settle (Score:2)
But Panama already has a big hole [wikipedia.org] that goes right through it!
Re:Wait for the dust to settle (Score:2)
Actually Panama hashing is broken, but the underlying idea is nevertheless worthwhile and will hopefully see more attention.
Re:What should we use now? (Score:2)
One of the weakest uses of MD5 in light of these discoveries is using the trusted digest of a file to validate files downloaded from untrusted sources/mirrors. FWIW, try using MD5 hash for the whole file, and then a second one for the first 512 bytes of a file. Then compare the trusted pair of hashes and file size against what you downloaded.
Until we get good data on the performance of this MD5 collision generator, we cannot know how much more difficult it would be to break the authentication scheme I sug
Re:MD5, SHA1 (Score:1)