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

131–140 of 524 posts

Re: Announcing the first SHA-1 collision

#131

Post by pavfarb »

mckoss wrote: post #37

Computing a collision today costs about $100K from my reading of the paper. So most uses of SHA1 are protecting documents of far lower value, and would not be likely attack targets (today).

SHA1 use cases are not limited into integrity verification of documents, but used a lot for traffic integrity and generation of authentication codes:

- Torrents of all kinds. - Version control systems (where ability attacks like displacing release pointers become easier). - IpSec, SSH, PGP and a number of other protected data exchange systems.

Being able to subvert integrity guarantees is a nice building block for complicated man-in-the-middle attacks.

Re: Announcing the first SHA-1 collision

#132

Post by [deleted] »

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…

[deleted]

Re: Announcing the first SHA-1 collision

#135

Post by arenaninja »

raphaelj wrote: post #47
jasode wrote: post #16

>Nine quintillion computations; 6,500 years of CPU; 110 years of GPU Is there a rough calculation in terms of today's $$$ cost to implement the attack?

They provide an estimate in their paper: > The monetary cost of computing the second block of the > attack by renting Amazon instances can be estimated from > these various data. Using a p2.16xlarge instance, > featuring 16 K80 GPUs and nominally costing > US$ 14.4 per hour would cost US$ 560 K for the > necessary 71 device years. It would be more economical > for a patient attacker to wait for low “spot prices” of >…

I wonder if this is really the case.

Because if we can drive storage costs much closer to zero (e.g.: a beefed up local server), we can keep storing hashes and the next collision should be much closer. Starting and stopping and throwing away the previous work does work out to $560K per collision, but doesn't it just keep getting cheaper if you keep going?

Re: Announcing the first SHA-1 collision

#136

Post by yAnonymous »

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 will mess up torrent sharing websites in a hurry.

I doubt it. Should this ever become a problem, it would be trivial to change the hashing algorithm. Not worth the effort.

Re: Announcing the first SHA-1 collision

#137

Post by sangnoir »

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?

Someone has discovered a computational equivalent of bypassing tamper-proof seals, but only a specific brand of seals (SHA1) which is very currently popular. Other types of seals still work fine. This means we can no longer trust if the cake from the baker hasn't been tampered with even though the packaging it comes in has an intact SHA1 seal, we should therefore demand that the baker start using SHA256 seals lest we get poisoned by the delivery boy who wants to steal the shiny PS4 he noticed the other day.

Edit: perhaps delivery boy underplays how costly the attack currently is. Perhaps make the poisoner a person of means who wants inheritance money. As the attack costs go down, even delivery boys will start to afford it, multiplying the risk.

Re: Announcing the first SHA-1 collision

#138

Post by cesarb »

geocar wrote: post #42
giovannibajo1 wrote: post #20

Earlier quoted context omitted.

This is not a pre-image attack, so you can't create a file that matches an existing SHA1. It's a collision attack, so you can create two files whose SHA1 is the same. So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users. What is currently st…

> What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel. I'm not convinced that's good enough. In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail. [1]: http://swtch.com/r.zip

That was changed early on git's history. Originally, the object was hashed after being compressed; it was changed to be hashed before being compressed.

See this commit: https://github.com/git/git/commit/d98b46f8d9a3daf965a39f8c00...

Re: Announcing the first SHA-1 collision

#139

Post by simias »

antoinealb wrote: post #92
anilgulecha wrote: post #67

Earlier quoted context omitted.

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.

SHA hashes cannot protect you against the distribution site getting compromised and the hash replaced. That is why most package manager include a form of cryptographic signatures (e.g. Ed25519 for OpenBSD's). SHA and MD5 hashes are just used to protect against accidental corruption, not targeted attacks.

You can use SHA for this purpose if you retrieve the hashes from a trusted and secured source.

Buildroot does that for 3rd party packages for instance. It downloads the source from the original website (possibly completely non-secured) but then validates the checksum against a locally trusted hash list. Buildroot supports a variety of hash algorithms but many packages still use SHA-1.

Post reply on HN