Announcing the first SHA-1 collision • Hacker News Board

Re: Announcing the first SHA-1 collision

#41

Post by nabla9 » Thu, Feb 23, 2017, 1:32 PM UTC

rntz wrote: post #28

rocqua wrote: post #23

Earlier quoted context omitted.

What about git? This makes it technically possible to get a backdoored linux repo with the same commit hash. EDIT: this is wrong, it's not a second pre-image attack only a collision attack. That is, you can create 2 git repositories with the same commit hash, but not a git repo that matches an already existing repo. In other words, you can create 2 things with the same hash, but can't control what that hash actually…

EDIT: My original comment was wrong. Git commit signing apparently only signs the commit hash itself, so it's only as trustworthy as the integrity of the hash. However, see also other comments which point out that this isn't a pre-image attack; you can't find a collision for a given thing (in this case, the linux kernel); rather, you can generate from scratch two pieces of data which happen to collide. Still, this is…

>git has commit signing

What the commit actually signs? Is it the sha1 hash?

Re: Announcing the first SHA-1 collision

#42

Post by geocar » Thu, Feb 23, 2017, 1:32 PM UTC

giovannibajo1 wrote: post #20

koolba wrote: post #11

What's the impact to something like git that makes extensive use of SHA-1? In their example they've created two PDFs with the same SHA-1. Could I replace the blob in a git repo with the "bad" version of a file if it matches the SHA-1?

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.

I'm not convinced that's good enough.

In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail.

[1]: http://swtch.com/r.zip

Re: Announcing the first SHA-1 collision

#43

Post by c3833174 » Thu, Feb 23, 2017, 1:33 PM UTC

ktta wrote: post #7

Here's a good blog about how SHA-1 works: http://www.metamorphosite.com/one-way-hash-encryption-sha1-d... . The biggest risk I see with this is how torrents are affected: https://en.wikipedia.org/wiki/Torrent_poisoning There's also a problem with git, but I don't see it being that as susceptible as torrents: http://stackoverflow.com/a/34599081/6448137

>torrents

Good, if something stronger and better comes out it'll still be a win.

Re: Announcing the first SHA-1 collision

#44

Post by gcp » Thu, Feb 23, 2017, 1:33 PM UTC

RyanZAG wrote: post #39

Is a 30 day disclosure period really enough for something like this? It's obviously not possible to 'fix' big systems that rely on SHA-1 such as git or github in only 30 days. Hardware devices that use SHA-1 as a base for authenticating firmware updates?

SHA1 was shown to be flawed in 2005. That's more than 30 days ago.

Re: Announcing the first SHA-1 collision

#45

Post by anilgulecha » Thu, Feb 23, 2017, 1:33 PM UTC

RyanZAG wrote: post #39

Is a 30 day disclosure period really enough for something like this? It's obviously not possible to 'fix' big systems that rely on SHA-1 such as git or github in only 30 days. Hardware devices that use SHA-1 as a base for authenticating firmware updates?

The article states 90 days.

> we will wait 90 days before releasing code that allows anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images with some pre-conditions

Re: Announcing the first SHA-1 collision

#46

Post by jasode » Thu, Feb 23, 2017, 1:33 PM UTC

scrollaway wrote: post #27

jasode wrote: post #16

>Nine quintillion computations; 6,500 years of CPU; 110 years of GPU Is there a rough calculation in terms of today's $$$ cost to implement the attack?

The PDF says: > Using a p2.16xlarge instance, featuring 16 K80 GPUs and nominally costing US 14.4 per hour would cost US 560 K for the necessary 71 device years

Thank you. It took me a while to realize that the paper you're citing is not directly linked in the Google blog article. It is actually found at shattered.io:

http://shattered.io/static/shattered.pdf

Re: Announcing the first SHA-1 collision

#47

Post by raphaelj » Thu, Feb 23, 2017, 1:34 PM UTC

jasode wrote: post #16

>Nine quintillion computations; 6,500 years of CPU; 110 years of GPU Is there a rough calculation in terms of today's $$$ cost to implement the attack?

They provide an estimate in their paper:

> The monetary cost of computing the second block of the

> attack by renting Amazon instances can be estimated from

> these various data. Using a p2.16xlarge instance,

> featuring 16 K80 GPUs and nominally costing

> US$ 14.4 per hour would cost US$ 560 K for the

> necessary 71 device years. It would be more economical

> for a patient attacker to wait for low “spot prices” of

> the smaller g2.8xlarge instances, which feature four K520

> GPUs, roughly equivalent to a K40 or a GTX 970. Assuming

> thusly an effort of 100 device years, and a typical spot

> price of US$ 0.5 per hour, the overall cost would be of

> US$ 110 K.

Re: Announcing the first SHA-1 collision

#48

Post by beagle3 » Thu, Feb 23, 2017, 1:34 PM UTC

rntz wrote: post #28

rocqua wrote: post #23

Earlier quoted context omitted.

What about git? This makes it technically possible to get a backdoored linux repo with the same commit hash. EDIT: this is wrong, it's not a second pre-image attack only a collision attack. That is, you can create 2 git repositories with the same commit hash, but not a git repo that matches an already existing repo. In other words, you can create 2 things with the same hash, but can't control what that hash actually…

EDIT: My original comment was wrong. Git commit signing apparently only signs the commit hash itself, so it's only as trustworthy as the integrity of the hash. However, see also other comments which point out that this isn't a pre-image attack; you can't find a collision for a given thing (in this case, the linux kernel); rather, you can generate from scratch two pieces of data which happen to collide. Still, this is…

The signature affirms the validity of the SHA1 hash, so ... the GPG is not more helpful than the underlying SHA1.

Re: Announcing the first SHA-1 collision

#49

Post by [deleted] » Thu, Feb 23, 2017, 1:34 PM UTC

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…

[deleted]

Re: Announcing the first SHA-1 collision

#50

Post by baq » Thu, Feb 23, 2017, 1:34 PM UTC

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…

i can imagine the torrent thing to be worth the $100k per collision.