[HN Gopher] Colliding Secure Hashes
___________________________________________________________________
Colliding Secure Hashes
Author : Retr0id
Score : 76 points
Date : 2023-12-21 08:49 UTC (1 days ago)
(HTM) web link (www.da.vidbuchanan.co.uk)
(TXT) w3m dump (www.da.vidbuchanan.co.uk)
| brohee wrote:
| 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 wrote:
| MD5 is also broken for much worse reasons than only being 128
| bits long, you can generate collisions near instantly
| AlexSW wrote:
| 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.
| brohee wrote:
| 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...
| saagarjha wrote:
| Depends on what the artifact is.
| ForkMeOnTinder wrote:
| 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?
| chrisshroba wrote:
| 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?
| Kalium wrote:
| 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.
| o11c wrote:
| No, that would require second preimage.
| brohee wrote:
| 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.
| Joker_vD wrote:
| Or you can just use SHA-256 instead and not bother with
| subtle details about which uses are safe and which are not.
| mr_mitm wrote:
| Still depends. Using SHA-256 for password storage is bad.
| Argon2 would be a much safer bet. Or maybe scrypt or
| yescrypt.
| postalrat wrote:
| And blindly use a suggestion from hn without understanding
| the tradeoffs.
| forward1 wrote:
| 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.
| upofadown wrote:
| Technically, 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 wrote:
| Or find ways to easily compare them without doing it
| manually.
| Vecr wrote:
| Chopping (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 wrote:
| Not 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/
| CodesInChaos wrote:
| Unless 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.
| remram wrote:
| I like the conclusion. Is there a standard scheme for hash-
| function-then-key-derivation? You can easily tell users to run
| `sha256sum` but...
|
| Though I suppose you should use public-key cryptography (e.g.
| GPG) if you want users to verify downloads to guard from
| _attacks_ rather than just _errors_.
|
| GPG/TLS/... should probably use different fingerprint algorithms
| though.
| Avamander wrote:
| I think it's less about the algorithm, it's more about the
| representation. If the goal is that users verify these things.
|
| SSH displays pubkey art when generating a new key. We've had
| secret recovery phrases for a while, they're long but really
| difficult to confuse with each other even if it's just a short
| glance. I think OpenPGP had something like that even. Then
| there's also GitHub that generates (or generated at some point)
| a custom unique profile picture for users. There are many other
| similar approaches out there.
|
| It would be possible to create a standard for representing
| SHA256/SHA512 hashes as human-comparable images. Possibly
| enhanced with checksum words or with machine readability for
| those paranoid (without error-prone OCR).
___________________________________________________________________
(page generated 2023-12-22 23:02 UTC)