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

121–130 of 524 posts

Re: Announcing the first SHA-1 collision

#121

Post by eth0up »

babyrainbow wrote: post #86
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?

There is/was this: https://arstechnica.com/security/2016/11/elegant-0day-unicor...

Re: Announcing the first SHA-1 collision

#122

Post by andai »

chaosfox wrote: post #91
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…

this isn't quite true, bittorrent have checksums for each piece in the torrent, I not saying its impossible to do but its significantly harder than just finding 2 files with the same hash.

Does bt have checksums for pieces and files? I thought it was only pieces.

Re: Announcing the first SHA-1 collision

#123

Post by kbart »

nstj wrote: post #107
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…

I don't actually know the in's and out's of BitTorrent structure but wouldn't that not work as the 2 files would be completely different? ie: I'd be downloading (and putting together) some blocks of the "real" movie and some blocks of the "malware". I'm guessing the resultant file wouldn't even open?

Video files are purposely made to work even with some data blocks missing. It's the feature that enables video streaming. Valid header is usually enough for video player to at least try to play a file.

Re: Announcing the first SHA-1 collision

#124

Post by kriro »

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?

By design, in case of a collision the new version will not replace the old (older version has preference in case of a collision). Not sure if you could somehow fiddle with the meaning of old and new from the systems POV though.

Re: Announcing the first SHA-1 collision

#125

Post by nabla9 »

rnhmjoj wrote: post #52

About tor: if an attacker produces a public key that collides with the SHA-1 hash of someone else's hidden service, then he would still need to generate the corresponding RSA-1024 private key, which is infeasible as of today. Is this correct?

The method presented works only with data formats where you can add section of 'calculated junk' into the data.

Public key can't contain junk and work, so I don't see how this method would work.

Re: Announcing the first SHA-1 collision

#126

Post by arenaninja »

ktta wrote: post #104
jgrahamc wrote: post #95

How am I going to explain this to my wife? Actually a serious question. How do we communicate something like this to the general public?

You don't really need to talk to anybody about this except people who torrent both illegal and legal torrents. Torrent poisoning is the most ripe for exploitation and the one with the highest return for a malicious attacker. So when you talk to someone who torrents, just tell them that the way the torrents verify a file is the correct one is no longer secure, and they have to keep an eye out for the next software upd…

As has already been mentioned, the digest of a torrent's pieces is also checked

Source: my own crappy implementation of a BitTorrent client, e.g.: https://github.com/charmeleon/BitClient/blob/master/src/conn...

Re: Announcing the first SHA-1 collision

#127

Post by pgeorgi »

koolba wrote: post #99
pgeorgi wrote: post #88

Earlier quoted context omitted.

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 o…

> 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. Except you can't do that as this isn't a preimage attack. You can't create an arbitrary bad file matching an existing SHA-1 with this.

One of the good parts of doing it at the leaf hashes over the top level hash as proposed further up the thread is that quicktime/avi/etc are much more amenable to carrying some "junk" data than trying to figure out two colliding merkle tries with the same hash.

Re: Announcing the first SHA-1 collision

#128

Post by kbart »

lawless123 wrote: post #111
mavdi wrote: post #84

Earlier quoted context omitted.

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

If they MPAA could subvert torrents of their property and and replace sections of the footage with just warnings (ruinning the download) i would find that much less objectionable than DRM. Frustrate the people pirating instead of punishing everyone else.

If such technique would be as accurate as their DCMA take-down notices, I wouldn't be surprised in resulting subverted Linux installations and whatnot.

Re: Announcing the first SHA-1 collision

#129

Post by sp332 »

runeks wrote: post #115
dragonwriter wrote: post #103

Earlier quoted context omitted.

I may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?

Not only that, BitTorrent also uses a Merkle tree of the torrent data split into pieces (e.g. 1 MB per piece), meaning you need to compute thousands of colliding hashes, with the added restriction that the data must be exactly the piece length. The torrent ID is the Merkle root hash, which is a hash of all the piece-hashes hashed together in a tree structure: https://i.stack.imgur.com/JVdvj.png

If you find a collision for the smallest piece, you don't need to find collisions for any higher nodes on the Merkle tree because you'll just be hashing the same values as the legit version.

Re: Announcing the first SHA-1 collision

#130

Post by the8472 »

runeks wrote: post #115
dragonwriter wrote: post #103

Earlier quoted context omitted.

I may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?

Not only that, BitTorrent also uses a Merkle tree of the torrent data split into pieces (e.g. 1 MB per piece), meaning you need to compute thousands of colliding hashes, with the added restriction that the data must be exactly the piece length. The torrent ID is the Merkle root hash, which is a hash of all the piece-hashes hashed together in a tree structure: https://i.stack.imgur.com/JVdvj.png

Most torrents use a flat list of hashes. The merkle tree is an extension. With a collision you could replace the metadata wholesale though, pointing at completely different content.

But then the torrent client would also present that different content from the start when asking you what to save.

Post reply on HN