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

61–70 of 524 posts

Re: Announcing the first SHA-1 collision

#61

Post by problems »

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

I don't think we're likely to see it used for torrent poisoning if it takes 110 GPUs 1 year to compute a collision - the electricity costs for such a rig would be enormous. 110 GPUs * about 300 W each = about 290 thousand kilowatt hours to break. Electricity costs of at least 10s of thousands of dollars. For a single torrent. You better be damn confident that those torrenters are going to go buy your product and that they won't just go to the next torrent down the list.

That said, attacks only get better, so it could happen at some point in the future and it's probably worth switching the hash function used sooner rather than later.

Re: Announcing the first SHA-1 collision

#62

Post by contravariant »

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…

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many).

Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

Re: Announcing the first SHA-1 collision

#63

Post by ktta »

anilgulecha wrote: post #56
c3833174 wrote: post #43

Earlier quoted context omitted.

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

Bittorrent is not a static/unchanged old protocol. It has constantly evolved to keep up with any attacks that could be mounted on it's distributed nature. I'm sure a BEP will also come up, and speedtracked on the back of this news.

The importance of that update cannot be understated. Torrents are much more viable to being exploited than anything else out there.

I think everyone should be on alert for updates to their favorite torrent softwares.

Re: Announcing the first SHA-1 collision

#64

Post by RubyPinch »

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?

git does some other funky things, usually it just uses the pre-existing object, or crashing

http://stackoverflow.com/a/9392525

It might change, but the response could quite likely be a stubborn "I said no before, so I'll say no now"

- - -

This attack has been known since 2013, that is a really long disclosure time (the main thing today is proving that the attack isn't theoretical)

Re: Announcing the first SHA-1 collision

#65

Post by scrollaway »

nabla9 wrote: post #41
rntz wrote: post #28

Earlier quoted context omitted.

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?

The commit object is signed; which contains a signature to both the tree and the parent. I don't see it as feasible to do a collision on both at once with the method outlined here, but maybe I'm missing something.

Tagging on the other hand is at risk, as it's just the hash that's signed.

Edit: You can check what is actually signed with `git cat-file -p $obj` where $obj is a commit or tag id.

Re: Announcing the first SHA-1 collision

#66

Post by maxtaco »

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…

PGP V4 key fingerprints still use SHA-1 exclusively. There hasn't been an update to this part of the RFC as far as I know [1]. Collisions where both preimages are of the attacker's choosing matter less in this context, but who knows what clever attacks people can come up with.

[1] https://tools.ietf.org/html/rfc4880#page-71

Re: Announcing the first SHA-1 collision

#67

Post by anilgulecha »

contravariant wrote: post #62
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…

>* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many). Maybe I'm mistaken, but isn't the purpose of those mainly to verify that you've downloaded the file correctly? At least, the use of MD5 suggests that this is the case.

Correct, and if you have 2 images that have the same hash, you can serve one or the other at different times. This is the attack.

Re: Announcing the first SHA-1 collision

#68

Post by adrianN »

cphoover wrote: post #26
nickez wrote: post #9

Earlier quoted context omitted.

On the shattered webpage: This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.

So... you are saying I couldn't do this on my Macbook's Core i7?

If you're very careful with your machine maybe you can make it last 6500 years, but I think that is way outside the expected lifetime of a mobile CPU under full load.

Re: Announcing the first SHA-1 collision

#69

Post by koolba »

anilgulecha wrote: post #59
fivesigma wrote: post #54

Earlier quoted context omitted.

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.

Create 2 torrents with the same hash. Release one into the wild. Wait. Infect.

Torrents have a tree of hashes for the parts. That allows validating pieces without the entire file (which is also validated at the end).

Probabilistically, the hashes of the parts would not match even if the top level hash matched.

Re: Announcing the first SHA-1 collision

#70

Post by rocqua »

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…

Yep, I saw that and edited as needed.

Isn't there still an attack where you create to different commits to the linux kernel with the same hash? (I presume here that a git commit hash is calculated over the diffs, not the end state of the repo).

If that is the case, you can still sneak code into the repo, though it would be easy to detect by seeing repos diverge.

Post reply on HN