Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing the first SHA-1 collision

security.googleblog.com

Post reply on HN
Print view View original

271–280 of 524 posts

Re: Announcing the first SHA-1 collision

#271

Post by 0x0 »

consp wrote: post #238
simias wrote: post #219

Earlier quoted context omitted.

Even if you use exactly the same headers it means that at the moment the SHA1 algorithm encounters the specially crafted data that creates the collision it's in a different state than with the "naked" files, so the collision (very probably) won't happen. Adding more content at the end of the file would work though, since at this point the SHA1 state machine would be in the same state on both sides. You can test that…

True, but the attack already builds upon modifying the state machine to get the same end result, creating data to allow for a specific prefix (e.g. always getting the desired intermediary state) should also be doable in some form of this attack.

Would it help if we padded the prefix so that the rest of the files are aligned to the block size of SHA1 (512bits), so that the crafted blocks are still block-aligned? Or does the different initial state (due to a different prefix) break any chance of re-colliding with these specific files? (i.e. you'll have to run the full brute force attack again with a valid git blob header as a common prefix?)

Re: Announcing the first SHA-1 collision

#272

Post by 0x0 »

anilgulecha wrote: post #259
kinkrtyavimoodh wrote: post #245

Earlier quoted context omitted.

No, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]— $ git cat-file -p fdf4fc3 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 author Scott Chacon 1243040974 -0700 committer Scott Chacon 1243040974 -0700 first commit A commit object just points to the tree obj…

Correct -- I was being terse: the commit is a function of the changes going in (and metadata like time, authorship). Details: https://gist.github.com/masak/2415865

I'm not really talking about entire git commits, but just single files (blobs) within any commit/tree/repository

Re: Announcing the first SHA-1 collision

#273

Post by cavanasm »

SamBam wrote: post #190

I'm confused by the "File Tester" at https://shattered.it/ It says "Upload any file to test if they are part of a collision attack." When I upload either of their two sample collision documents, it says they are "Safe."

I get "Collision found". Couldn't even begin to guess what's causing it to say it's safe on your end, unless you modified the files.

Re: Announcing the first SHA-1 collision

#274

Post by VMG »

inetknght wrote: post #162
yAnonymous wrote: post #136

Earlier quoted context omitted.

>This will mess up torrent sharing websites in a hurry. I doubt it. Should this ever become a problem, it would be trivial to change the hashing algorithm. Not worth the effort.

How do you propose to ensure backwards compatibility with the millions of torrents already produced?

New clients could support multiple hash algs, so old torrents would not be a problem. New torrents could provide hashes for multiple algs, depending on the extensiblity of torrent format. Otherwise the torrent sites could provide two URLs or torrent files.

Re: Announcing the first SHA-1 collision

#275

Post by Twirrim »

amichal wrote: post #224

Linked http://shattered.io/ has two PDFs that render differently as examples. They indeed have same SHA-1 and are even the same size. $ls -l sha*.pdf -rw-r--r--@ 1 amichal staff 422435 Feb 23 10:01 shattered-1.pdf -rw-r--r--@ 1 amichal staff 422435 Feb 23 10:14 shattered-2.pdf $shasum -a 1 sha*.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf Of cou…

The PDF example given is somewhat ridiculous.

"For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract. "

Talk about ridiculous scenarios only people living in a tech bubble could come up with.

How many landlords do you imagine know what sha-1 checksums even are, let alone would try and use it as proof the evil version of the rental agreement is incorrect?

"I would have gotten away with it, if it wasn't for you meddling kids and your fancy SHA-256 checksums!"

Re: Announcing the first SHA-1 collision

#276

Post by rlanday »

mikeash wrote: post #150

For those of us who are totally clueless about the construction of these hash functions, what is the fundamental flaw in SHA-1 that allows this attack? How do newer hash functions avoid it?

From what I understand, no hash function has ever stood the test of time as some block ciphers have. SHA-2 is of related design and although no one's found an effective collision attack yet, I don't think it would really surprise anyone if one were found. This was in large part the motivation for picking a SHA-3. If you use SHA-3, it's of unrelated design to SHA-1, but it's also much newer and hasn't gotten as much cryptanalysis yet.

Re: Announcing the first SHA-1 collision

#277

Post by polynomial »

It appears they are using a 2^63 hash operation attack that has been well known for nearly a decade. (Brute force of SHA-1 is 2^69.)

I wonder why they did not use the 2^52 operation attack that Schneier noted in 2009?

https://www.schneier.com/blog/archives/2009/06/ever_better_c...

Re: Announcing the first SHA-1 collision

#279

Post by rlanday »

OJFord wrote: post #209
giovannibajo1 wrote: post #20

Earlier quoted context omitted.

This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same. So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users. What is currently st…

> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. Hang on, that doesn't matter though, does it? I was under the impression that git's SHAs were to be treated as repo-wise unique; not universally. There must non-adversarial 'collisions' across repositories already, surely? I thought this attack potentially allows creating two commits in the same re…

I don't think there's ever been an example of two different pieces of content hashing to the same SHA-1 before. An infinite number of such examples obviously must exist but they're incredibly improbably to encounter by accident.

Re: Announcing the first SHA-1 collision

#280

Post by [deleted] »

OJFord wrote: post #209
giovannibajo1 wrote: post #20

Earlier quoted context omitted.

This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same. So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users. What is currently st…

> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. Hang on, that doesn't matter though, does it? I was under the impression that git's SHAs were to be treated as repo-wise unique; not universally. There must non-adversarial 'collisions' across repositories already, surely? I thought this attack potentially allows creating two commits in the same re…

[deleted]
Post reply on HN