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

191–200 of 524 posts

Re: Announcing the first SHA-1 collision

#191

Post by Natanael_L »

Ajedi32 wrote: post #156
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…

Edit: Nevermind, I misinterpreted something in the report. Collisions between malicious and non-malicious documents are indeed most likely feasible. Original comment: While theoretically possible, I don't really see that particular attack as being an actual, practical problem anytime soon. In order for that to work not only would you have to find _a_ collision, but you'd have to find one with the additional constrain…

No, that's not the big problem. Every collision of this kind so far just requires a random looking section, and allows another section to be whatever you want. You can just swap out one file for malware.

Re: Announcing the first SHA-1 collision

#192

Post by mikeash »

an_d_rew wrote: post #173
mikeash wrote: post #150

For those of us who are totally clueless about the construction of these hash functions, what is the fundamental flaw in SHA-1 that allows this attack? How do newer hash functions avoid it?

The newest SHA members are based on sponge functions. http://keccak.noekeon.org/ gives a good overview.

Thank you, great link.

Re: Announcing the first SHA-1 collision

#193

Post by 0x0 »

anilgulecha wrote: post #185
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…

That's not the attack on git -- it's the commit ID. You can have two patches that have the same commit. Apply one now, and in the future replace it with the second one, without affecting any other commits IDs afterwards.

But I thought files in git were also identified by the sha1 of their contents? Why isn't there a conflict/de-duplication happening when committing one file over the other? I must be misunderstanding something, but I thought the commit points to a hash of a tree (file list) which has a list of blobs (file referenced by their sha1 sum), how does it know which of the two pdf file blobs to pick out of the blob store?

Re: Announcing the first SHA-1 collision

#194

Post by hannob »

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…

Git stores the files as so-called blob objects, they're prefixed with a simple header. So even if sha1(file1)==sha1(file2), your git will still get different hashes, because it's doing sha1(prefix+file1), sha1(prefix+file2). You'd need a file that collides with this prefix. This is certainly possible, but not sure if it may mean you need to pay for that several thousand cpu/gpu cluster google used to make it feasible. Maybe there are precomputations that can be reused somehow.

Re: Announcing the first SHA-1 collision

#195

Post by Aissen »

Natanael_L wrote: post #187
Aissen wrote: post #169

Earlier quoted context omitted.

Then this smallest piece must also change the file type to an executable, and contain a meaningful payload.

Polyglot files are trivial to create, that's the easiest part here.

I didn't say it wasn't, it was for context. Also you need to be polyglot + have enough space for the collision computation.

I just checked, it should be really easy. A piece/chunk size in torrents is 64kB. The total size of each PDF in the paper is 2.7kB.

Re: Announcing the first SHA-1 collision

#198

Post by Natanael_L »

sktrdie wrote: post #149
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…

But you can't control the data in the malware. It will be garbage.

They controlled the visual appearance of the different PDF files in the example. Why couldn't you inject malware instead?

Re: Announcing the first SHA-1 collision

#199

Post by [deleted] »

sktrdie wrote: post #149
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…

But you can't control the data in the malware. It will be garbage.

[deleted]

Re: Announcing the first SHA-1 collision

#200

Post by jakeogh »

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.

On the other hand it's useful for denial of service. If you want to disrupt a swarm feeding it bad data is 'good enough'.
Post reply on HN