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

241–250 of 524 posts

Re: Announcing the first SHA-1 collision

#241

Post by CydeWeys »

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?

Plenty of people download executables on BitTorrent too, so it'd be easier just to target that. Go inject your malware into a popular torrent for pirating the latest version of Photoshop, or Windows, or a popular game.

Re: Announcing the first SHA-1 collision

#242

Post by problems »

m3ta wrote: post #144

To put things into perspective, let the Bitcoin network hashrate (double SHA256 per second) = B and the number of SHA1 hashes calculated in shattered = G. B = 3,116,899,000,000,000,000 G = 9,223,372,036,854,775,808 Every three seconds the Bitcoin mining network brute-forces the same amount of hashes as Google did to perform this attack. Of course, the brute-force approach will always take longer than a strategic appr…

A few considerations though:

- Google used GPUs, much of the Bitcoin network relies on fully custom ASICs now and mining without them isn't really profitable anymore

- SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs, so if someone were to go out and build SHA1 ASICs, you could probably do this very, very fast. It's almost certain that intelligence agencies could invest this effort to say, break SHA1 SSL certs.

Re: Announcing the first SHA-1 collision

#243

Post by digler999 »

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…

wont an easy fix be to just hash it again with sha256? Sure that will take time to bake it into software, but wont they just be able to put a text label next to the description and say "sha256: abc...123" ?

Re: Announcing the first SHA-1 collision

#244

Post by js2 »

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…

This is because git adds a header and zlib compresses the PDFs such that they no longer collide when stored in git. But of course, they still collide when extracted from git:

    $ ls -l; for i in 1 2; do sha1sum
See "Object Storage" for details at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

It's worth noting that either of the changes, adding a header or deflating the content, would remove the collision. The former because this is a chosen-prefix collision attack, the latter because the compression alters the content entirely.

I'm not a cryptographer, so I wonder: do the git header and zlib compression add significant complexity to manufacturing two files that collide inside git?

Re: Announcing the first SHA-1 collision

#245

Post by kinkrtyavimoodh »

anilgulecha wrote: post #204
0x0 wrote: post #193

Earlier quoted context omitted.

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?

No, each commit (or merge) is simply the SHA1 of the diff-patch. Thus adding the second file does create a diff, since the contents are not the same.

No, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]—

  $ git cat-file -p fdf4fc3
  tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
  author Scott Chacon  1243040974 -0700
  committer Scott Chacon  1243040974 -0700

  first commit
A commit object just points to the tree object (in turn, another SHA-1, this time of the complete directory listing) and other meta information such as author name etc.

[1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Re: Announcing the first SHA-1 collision

#246

Post by sp332 »

icedchai wrote: post #83

> "10 years after of SHA-1 was first introduced" wasn't SHA-1 introduced in the 90's?

Looks like a typo. They might have been referring to sucessful cryptanalysis of SHA-1 which seems to have started around 2005 https://en.wikipedia.org/wiki/SHA-1#Cryptanalysis_and_valida... or maybe the BOINC project to create a collision, which did start 10 years ago.

Re: Announcing the first SHA-1 collision

#247

Post by cjbprime »

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?

> How am I going to explain this to my wife?

I don't know. What's your wife's background? If she already knows what one-way functions are, you could just explain that we've found collisions for the first time in an old one-way function that was used for file authenticity but isn't used much anymore because we knew ten years ago we were probably going to start finding collisions in it.

If she doesn't know what one-way functions are, it seems like something that could be explained with examples to an average person who was interested in learning?

Re: Announcing the first SHA-1 collision

#248

Post by bb88 »

kzrdude wrote: post #108
icedchai wrote: post #83

> "10 years after of SHA-1 was first introduced" wasn't SHA-1 introduced in the 90's?

Git was released in 2005, 12 years ago, and it's based around SHA-1. They've done a massive miscalculation there.

OTOH, 12 years of reliability from a checksum in the age of Moore's law and quantum computers is pretty good, frankly.

I don't think they ever expected sha-1 to survive forever.

Re: Announcing the first SHA-1 collision

#249

Post by Natanael_L »

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.

If you created the original torrent then you can do it
Post reply on HN