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

331–340 of 524 posts

Re: Announcing the first SHA-1 collision

#331

Post by kzrdude »

js2 wrote: post #244
0x0 wrote: post #180

I'm trying to play with this in git. Added the first file, committed, and then overwrote the file with the second file and committed again. But even when cloning this repository into another directory, I'm still getting different files between commit 1 and 2. What does it take to trick git into thinking the files are the same? I half expected "git status" to say "no changes" after overwriting the first (committed) pd…

This is because git adds a header and zlib compresses the PDFs such that they no longer collide when stored in git. But of course, they still collide when extracted from git: $ ls -l; for i in 1 2; do sha1sum See "Object Storage" for details at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It's worth noting that either of the changes, adding a header or deflating the content, would remove the collision. Th…

Probably just as easy. They used a fixed header for PDF and a tweakable middle. So just add the git blob header, as long as the tweakable middle is fixed size.

Re: Announcing the first SHA-1 collision

#334

Post by goncalomb »

pfg wrote: post #314
goncalomb wrote: post #298

https://security.googleblog.com : "This website uses a weak security configuration (SHA-1 signatures), so your connection may not be private."

I get a SHA256 certificate for that site. What user agent are you using? Is there some kind of middlebox on your network, or do you use AV software that intercepts TLS connections?

Fair enough, I was using Chrome "Version 50.0.2661.102 (64-bit)" on Linux Mint. I have updated it to 56.0.2924.87, now I'm getting a full error page "Your connection is not private" NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM. I need to search for this issue now.

No I'm not using anything that intercepts TLS connections.

EDIT: It's fixed now, `sudo apt-get install libnss3-1d`.

http://askubuntu.com/questions/880695/neterr-cert-weak-signa...

Re: Announcing the first SHA-1 collision

#335

Post by cbhl »

problems wrote: post #308
btilly wrote: post #307

Earlier quoted context omitted.

It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs. To the contrary, it is unlikely that they can do so. There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". It gets harder still if you're trying to add constraints about the format of your text (such as making…

> There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". Doesn't the PDF on their site pretty much prove they can do both of these - at least, in a way? They were able to change the color without impacting the contents of the PDF and get the same SHA1. They probably have a fair bit of garbage data to work with…

I haven't seen the actual PDFs, but the way my crypto prof taught me about this attack in college is that you generate a PDF of the form

    if (x == a) {
      // display good content
    } else {
      // display bad content
    }
You have to craft this PDF file in such a way that given a SHA1 collision (a, b) that the file with x = a and the file with x = b have the same SHA1. (There are some nuances about aligning to block boundaries, IIRC.)

Re: Announcing the first SHA-1 collision

#336

Post by makomk »

jsolson wrote: post #313
problems wrote: post #308

Earlier quoted context omitted.

> There is a world of difference between "come up with two things that hash to the same value" and "come up with something that hashes to a particular known value". Doesn't the PDF on their site pretty much prove they can do both of these - at least, in a way? They were able to change the color without impacting the contents of the PDF and get the same SHA1. They probably have a fair bit of garbage data to work with…

No. I don't know the details of the attack, but a third possibility (as I read it) is that both PDF documents are modified in the process until they arrive at a collision. PDF has the convenient property that you can inject arbitrary bogus data into the middle of it with a constant head and tail and it will still be valid. The tail of the file contains a trailer that points to the dictionary that describes where all…

Or, if you're really clever - and Ange Albertini is quite good at this kind of trick - you can design the PDF so that the different garbage in the middle causes the other, unchanged content to be interpreted differently in the two PDF files, possibly even designing it so that the intended contents of each PDF is treated as garbage and ignored entirely in the other PDF.

Re: Announcing the first SHA-1 collision

#337

Post by mike_hearn »

Twirrim wrote: post #275
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 ch…

Obviously the landlord doesn't know or care what SHA-1 is, but he may care if his Adobe Reader says "This file was signed by the Department of Housing" at the top of the screen when he opens the PDF. As Reader fully supports signed PDFs and they do get used, believe it or not, this attack is not theoretical.

Re: Announcing the first SHA-1 collision

#338

Post by gliptic »

mikegerwitz wrote: post #324
lisper wrote: 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…

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

#340

Post by mike_hearn »

fivesigma wrote: post #54
anilgulecha wrote: post #33

Big things affected: * DHT/torrent hashes - A group of malicious peers could serve malware for a given hash. * Git - A commit may be replaced by another without affecting the following commits. * PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.) * Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Edit: Yes, I understand this is a collision attack. But yes, it…

None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash. Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult). This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.

anilgulecha is correct. Consider the following attack:

You wish to undermine the security of an important codebase managed by git.

You write a valuable and useful contribution to the code. You also create another version of the commit that has the same SHA-1 as the first, which breaks the security of that code.

You submit the first commit, it is accepted and merged.

Now you wait for your target to do a git clone on the repository, perhaps because it's a build environment. You then MITM it (e.g. using infrastructure like QUANTUM INSERT) and redirect the clone to your own git server, which serves the bad commit.

The target compares the top commit hashes of what it expected to get and what it actually got, and is none the wiser. They now compile the code and produce a backdoored binary.

Post reply on HN