Hacker News new | ask | show | jobs
by AlexSW 907 days ago
As always, it depends what properties you're relying on MD5 for. Just because something uses MS5 doesn't mean it's broken, because its preimage resistance (i.e. 'invert this hash') and second preimage resistance (i.e. 'find an input that goes to the same hash of this other input') are both not broken (yet) from a practical perspective.

Sometimes whether a cryptographic protocol relies on collision resistance can be surprisingly nuanced, so it should be phased out for this alone (and as we have better options) but for simple examples (e.g. to make a signed hash of an executable, which is probably equivalent to what you're describing) it's not broken.

2 comments

Or you can just use SHA-256 instead and not bother with subtle details about which uses are safe and which are not.
Or you can't, for example because you already signed a 20 year root with SHA-1. Nor does it matter in this example and many others.
Still depends. Using SHA-256 for password storage is bad. Argon2 would be a much safer bet. Or maybe scrypt or yescrypt.
And blindly use a suggestion from hn without understanding the tradeoffs.
They often propose verifying downloads with it, and it's pretty easy for a project insider to build two artifacts with the same MD5, one clean and one not...
Aren't you already trusting the maintainer by downloading and running their software? An evil maintainer can publish any hash they want, so why would they go to the trouble of making a hash collision?
In some setups, you're required to trust both the maintainer and the mirror, which are not always the same party. If someone can generate a collision, it means a mirror can mount an attack even when the maintainer is corrected trusted.
No, that would require second preimage.
You can pass review that way. You publish a clean artifact that gets reviewed and vetted, and for the actual attack you replace the vetted artifact by the bad one. If you trust MD5, or as the article shows, even a good 128 bit hash, like truncated SHA-256, you get pwned. That's why you don't accept MD5 based signature as well.

People that take security seriously enough to check hashes should not trust MD5 so the scenario is not super credible, but people still publish MD5 hashed like it's the early 2000s.

That’s what I always wonder too. If we assume an attacker can change the contents at example.com/app.zip, why should we assume the hash published at example.com/download.html is any more secure?
Depends on what the artifact is.