4 ms·
He demonstrates without a doubt that 128 bit of hash is not enough, yet you can still find many projects still publishing MD5 hashes. The long tail of bad crypt
by brohee 3y ago
He demonstrates without a doubt that 128 bit of hash is not enough, yet you can still find many projects still publishing MD5 hashes. The long tail of bad crypto is extremely long.
- Retr0id 3y agoMD5 is also broken for much worse reasons than only being 128 bits long, you can generate collisions near instantly
- AlexSW 3y agoAs 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.
- brohee 3y agoThey 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...
- saagarjha 3y agoDepends on what the artifact is.
- ForkMeOnTinder 3y agoAren'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?
- chrisshroba 3y agoThat’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?
- Kalium 3y agoIn 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.
- o11c 3y agoNo, that would require second preimage.
- brohee 3y agoYou 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.
- Joker_vD 3y agoOr you can just use SHA-256 instead and not bother with subtle details about which uses are safe and which are not.
- mr_mitm 3y agoStill depends. Using SHA-256 for password storage is bad. Argon2 would be a much safer bet. Or maybe scrypt or yescrypt.
- postalrat 3y agoAnd blindly use a suggestion from hn without understanding the tradeoffs.
- forward1 3y agoOr 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.
- upofadown 3y agoTechnically, a software project does not have to worry about collisions for hashes verifying their releases. That only becomes a problem where there is some sort of trusted third party that can be tricked into authenticating one of a pair of collided hashes. There is a usability issue here. A 256 bit hash is so long as to be very hard to manually compare. A project might want to keep the length down to something reasonable.
- zcw100 3y agoOr find ways to easily compare them without doing it manually.
- Vecr 3y agoChopping (drop the first x bits) sha256 to 180 bits is probably the most secure way to go, see Block-Cipher-Based Tree Hashing by Aldo Gunsing. Bitcoin uses RIPEMD180 so the length is probably fine, but it has other properties that make chopped sha256 a better idea (length extension attacks for example).
- hedora 3y agoNot really. He generated some partially colliding 96 bit hashes, then threw away non-matching characters, and claimed to have a collision. If you let me pick which bits matter for collision detection, then I can make any secure hash collide with itself. On a related note, someone took the end of Contact to heart, and definitively proved that God is a Where's Waldo? fan: https://kundor.github.io/Finding-Waldo/ https://kundor.github.io/Finding-Waldo/
- Retr0id 3y agoI never threw away any non-matching characters, it's a full 96-bit collision, period.
- CodesInChaos 3y agoUnless the attacker has a big influence on the "good" binary, they need to find a second pre-image, not a collision for this to be a problem. The real problems with publishing hashes is that the source of the hash is generally just as (un)trustworthy as the binary itself, and that nobody bothers verifying them in the first place.