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

81–90 of 524 posts

Re: Announcing the first SHA-1 collision

#81

Post by koolba »

anilgulecha wrote: post #77
koolba wrote: post #69

Earlier quoted context omitted.

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.

The initial torrent metadata is pulled from nothing but the first hash. This is the point where the rest of the data forks.. someone gets the movie, another gets the .exe.

That's not an issue with the torrent. That would be with the magnet link format.

Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.

Re: Announcing the first SHA-1 collision

#84

Post by mavdi »

mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

To be honest this is a lovely evil plan. cough MPAA cough

Re: Announcing the first SHA-1 collision

#85

Post by [deleted] »

anilgulecha wrote: post #67
contravariant wrote: post #62

Earlier quoted context omitted.

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

[deleted]

Re: Announcing the first SHA-1 collision

#86

Post by babyrainbow »

mabbo wrote: post #74

One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…

Malware in a video? Is that possible? How does it work?

Re: Announcing the first SHA-1 collision

#87

Post by [deleted] »

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?

[deleted]

Re: Announcing the first SHA-1 collision

#88

Post by pgeorgi »

koolba wrote: post #69
anilgulecha wrote: post #59

Earlier quoted context omitted.

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.

You could (try to) collide one of the blocks at the end of the tree. The tree of hashes will still be the same since the hash of the block didn't change.

Then join the torrent with a client that doesn't download but only upload that block (there will be some that will pick it from you). Many legit copies, except for those that were so unlucky to fetch the block from you.

If you manage to build such a block based on one in recurring content (eg. a distributor's logo at the beginning of the file), it could be reused, too.

Re: Announcing the first SHA-1 collision

#89

Post by nabla9 »

scrollaway wrote: post #65
nabla9 wrote: post #41

Earlier quoted context omitted.

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

It seems that commit object contains metadata and sha1 hash of the commit tree. In other words, signing comment object is not detecting if data is altered somewhere in the tree and creates identical sha1 hash.

Re: Announcing the first SHA-1 collision

#90

Post by qjighap »

baq wrote: post #50
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.

You haven't seen my collection of cat pics torrent ;)

Also from a more serious stance the danger is the malware vector or the destruction of the ability to have integrity and not the data in the torrent itself.

Post reply on HN