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

71–80 of 524 posts

Re: Announcing the first SHA-1 collision

#71

Post by mkj »

problems wrote: post #61
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…

Malware infecting a few hundred beefy-gpu PCs isn't implausible.

Re: Announcing the first SHA-1 collision

#72

Post by hvidgaard »

gcp wrote: post #44
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?

SHA1 was shown to be flawed in 2005. That's more than 30 days ago.

Saying it was shown to be flawed is being nice. It was outright broken 12 years ago as it was shown that you could find collisions with far less complexity that a bruteforce attack.

What has happened is that someone created the code to actually carry out an attack, and showed that it will cost around $110K today.

Re: Announcing the first SHA-1 collision

#73

Post by prefect42 »

gcp wrote: post #44
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?

SHA1 was shown to be flawed in 2005. That's more than 30 days ago.

Right, the Wikipedia page for SHA1 does show research on a variety of possible attacks, starting from 2005.

Re: Announcing the first SHA-1 collision

#74

Post by mabbo »

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 got 1000 people purposely downloading ransomware from you- and sharing it with others.

Apparently it costs around $100,000 to compute the collisions, but so what? If I've got 10,000 installing my 1BTC-to-unlock ransomware, I'll get a return on investment.

This will mess up torrent sharing websites in a hurry.

Edit: some people have pointed out some totally legitimate potential flaws in this idea. And they're probably right, those may sink the entire scheme. But keep in mind that this is one idea off the top of my head, and I'm not any security expert. There's plenty of actors out there who have more reasons and time to think up scarier ideas.

The reality is, we need to very quickly stop trusting SHA1 for anything. And a lot of software is not ready to make that change overnight.

Re: Announcing the first SHA-1 collision

#75

Post by [deleted] »

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.

[deleted]

Re: Announcing the first SHA-1 collision

#76

Post by fivesigma »

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.

This requires the addition of random garbage in the first file which someone will detect anyway. Why not release an infected file with a timebomb malware instead of colliding SHA1? Much cheaper. Still, none of this allows you to attack an already existing torrent.

Re: Announcing the first SHA-1 collision

#77

Post by anilgulecha »

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.

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.

Re: Announcing the first SHA-1 collision

#78

Post by mikegerwitz »

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.

You could also find a preimage for any tree or blob object referenced by that commit. And in large projects, you have a lot to choose from.

(As has been stated, I know this isn't a second preimage attack.)

Edit: See my answers in this thread: https://lists.gnu.org/archive/html/bug-guix/2016-06/msg00009...

Re: Announcing the first SHA-1 collision

#79

Post by VMG »

daenney wrote: post #53
VMG wrote: post #19

Earlier quoted context omitted.

Funny, just yesterday I thought about what would be necessary to change and deploy this. Apparently the SHA1 hash wasn't designed as a security feature, but I would not be surprised if it is being abused as one today.

It's not used as a security feature in Git (though SHA-1 is designed as a cryptographically secure hash) but Git commit singing does use SHA-1 b/c GPG.

It's not supposed to be used as a security feature, but I think some tools use it as such. Dependency management tools that reference by SHA-1 hash come to mind. Of course they should have used other primitives all along, but we know how it is..

Re: Announcing the first SHA-1 collision

#80

Post by gajjanag »

necessity wrote: post #34

> If you use Chrome, you will be automatically protected from insecure TLS/SSL certificates, and Firefox has this feature planned for early 2017. No need to wait. The option to reject SHA-1 certificates on Firefox is `security.pki.sha1_enforcement_level` with value `1`. https://blog.mozilla.org/security/2016/01/06/man-in-the-midd... Other configs worth doing: `security.ssl.treat_unsafe_negotiation_as_broken` to `true…

Excellent.

More generally, there is this fantastic repo on github that lists a bunch of such things that can be tweaked in about:config (mostly from a security/privacy standpoint): https://github.com/pyllyukko/user.js

Post reply on HN