On a quick scroll of the comments, I haven't seen this posted so far: http://valerieaurora.org/hash.html We're at the "First collision found" stage, where the programmer reaction is "Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them", and the non-expert reaction is "Explain why a simple collision attack is still useless, it's really the second pre-image attack…
Announcing the first SHA-1 collision
361–370 of 524 posts
Re: Announcing the first SHA-1 collision
#362Huh? It's been around a lot longer than 10 years.
Re: Announcing the first SHA-1 collision
#363Earlier quoted context omitted.
Interesting premise, some objections: 1) wouldn't search time be proportional to file size for hashes? These guys worked on 400kb pdf's, while most popular torrent content is in the GB range 2) Wouldn't this only work for users that got the entire file from you? fileA and fileB may have the same hash, but some random portions from each will have a different hash.
You could replace a single chunk with your malware. Then it could be any size and the rest of the chunks could be the legit content. I don't know much about video codecs, but this assumes there's some way to break out of the playback and run your malicious code. Maybe a buffer overflow, or maybe if your malware is the first chunk of the file you could get it to run first somehow before the video? Or even better, torr…
If you have an exploit in a video player, you don’t really need the collision.
> You could swap that out undetected, and you can probably also convince people they have to run it with sudo.
Also don’t need a collision (or more sudo than usual) for this; just make it patch the application (like it’s supposed to!) with something that runs with low probability.
Re: Announcing the first SHA-1 collision
#364Re: Announcing the first SHA-1 collision
#365Earlier quoted context omitted.
Getting the first-preimage of the document and hashing that same preimage just gives you back the original hash---it's like an identity function. It doesn't give you a second document. Edit: I misinterpreted your message. I added "same" above to convey what I thought you were saying.
You seem to be mistaking or misreading something here. * Collision attack: find X and Y such that hash(X) = hash(Y) * Second-preimage: given X, find Y such that hash(X) = hash(Y) * First-preimage: given hash(X), find Y such that hash(X) = hash(Y) > If you have an encrypted message that you hashed/signed _before_ encrypting, and Eve wants to know what you said, first-preimage would be worse, and second-preimage wouldn…
Re: Announcing the first SHA-1 collision
#366Earlier quoted context omitted.
The severity between the preimage attacks depends on context. For Git, for example, a first-preimage attack won't buy you anything, but a second-preimage could be potentially devastating depending on how lucky you get. If Mallory wanted to make it look like you signed a document you didn't, second-preimage would be devestating. And with the demonstration of two PDFs sharing the same hash, this is a pretty severe one:…
If you can do a first-preimage attack, you can do a second-preimage attack. Just hash the document you have. Therefore a first-preimage attack is strictly more severe.
Re: Announcing the first SHA-1 collision
#367This point seems to be getting re-hashed (no pun intended) a lot, so here's a quick summary: there are three kinds of attacks on cryptographic hashes: collision attacks, second-preimage attacks, and first-preimage attacks. Collision attack: find two documents with the same hash. That's what was done here. Second-preimage attack: given a document, find a second document with the same hash. First-preimage attack: given…
why not??
Re: Announcing the first SHA-1 collision
#368Earlier quoted context omitted.
Wouldn't that make the attack easier , since you just have to manufacture a pair of pieces with the same hash, instead of having to make the whole file have the same hash?
that depends on the attacker objective, if you just want to trash the file you can just search for any piece that have a hash collision, but if you want to turn the file into a malware you will need to modify the file in a specific way, possibly spanning multiple pieces, and there's less room for fuzzing the hash.
All you need for the colliding pieces is for one to trigger the payload and the other not to trigger the payload.
Re: Announcing the first SHA-1 collision
#369Earlier quoted context omitted.
You seem to be mistaking or misreading something here. * Collision attack: find X and Y such that hash(X) = hash(Y) * Second-preimage: given X, find Y such that hash(X) = hash(Y) * First-preimage: given hash(X), find Y such that hash(X) = hash(Y) > If you have an encrypted message that you hashed/signed _before_ encrypting, and Eve wants to know what you said, first-preimage would be worse, and second-preimage wouldn…
You're missing something in your definition of a second-preimage attack, which is that Y != X.
Re: Announcing the first SHA-1 collision
#370Someone just made about $2500 See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013... and https://bitcoinchain.com/block_explorer/address/37k7toV1Nv4D...
That would offset a very, very tiny fraction of the cost of 56,940,000 CPU hours and 963,600 GPU hours.