Hacker News new | ask | show | jobs
by hackinthebochs 4625 days ago
What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain security concerns rather than relying on blanket catch-all declarations.
2 comments

And now I'd like to say for the third time that no, there was no "just use MD5" meme in cryptography or in software development, and if TLS is an illustration of anything, it's of not simply leaning on MD5. Once again: the TLS protocol itself is not vulnerable because of MD5, and it's not vulnerable because its designers and implementors both knew about and accounted for the weaknesses of MD5.

The author took the opposite lesson from TLS than the one that it actually demonstrates, and the commenter above is harping on that broken lesson.

As a computer scientist, it's a joy to discover when you're wrong about things. So I'm enjoying being on the wrong side of the discussion for once, because I'm learning lots.

Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.

:)
Has anyone said "just use MD5" to someone who wasn't about to use CRC32 instead?
Doubt about this exact case, but I've seen MD5 being (ab)used in a really weird ways, which I attributed to mindless "oh, I'll just use MD5 here, heard it's good for security!"

One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.

That scheme would be insecure even if it was SHA3(SHA2(SHA1(unix_timestamp()))