Live data from Hacker News

Announcing the first SHA-1 collision

security.googleblog.com

361–370 of 524 posts

Re: Announcing the first SHA-1 collision

#361
post #119

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…

Heh, RIPEMD-160, forever under peer review :)

Re: Announcing the first SHA-1 collision

#363

Earlier 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…

> 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?

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

#365
post #358

Earlier 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…

You're missing something in your definition of a second-preimage attack, which is that Y != X.

Re: Announcing the first SHA-1 collision

#366

Earlier 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.

Not if the second-preimage attack is properly defined to find a second distinct document with the same hash as the first.

Re: Announcing the first SHA-1 collision

#367
post #321

This 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…

> This point seems to be getting re-hashed (no pun intended)

why not??

Re: Announcing the first SHA-1 collision

#368
post #113

Earlier 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.

As mentioned else were in this thread, you can put a lot of the payload outside the single collision piece. People are unlikely to go looking for executable code inside a video.

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

#369
post #358

Earlier 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.

Ah good point. It could be that the first-preimage attack gets you exactly X, in which case it fails to handle second-preimage. I would expect this to be incredibly unlikely (especially since they seem to generally involve generating some random garbage). I would also expect most first-preimage attacks have a way to "continue" to a third value, eventually.

Re: Announcing the first SHA-1 collision

#370
post #140

Someone 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.

The person who collected it was most likely not a Google employee; just the first person to download those files who knew about the bounty.
Post reply on HN