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

151–160 of 524 posts

Re: Announcing the first SHA-1 collision

#151

Post by svantana »

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…

Interesting premise, some objections:

1) wouldn't search time be proportional to file size for hashes? These guys worked on 400kb pdf's, while most popular torrent content is in the GB range

2) Wouldn't this only work for users that got the entire file from you? fileA and fileB may have the same hash, but some random portions from each will have a different hash.

Re: Announcing the first SHA-1 collision

#152

Post by svantana »

throwaway2048 wrote: post #145
ktta wrote: post #96

Earlier quoted context omitted.

You could have a buffer overflow attack talking advantage of a specific popular video player out there. Since video players are usually not very security focused, someone determined could do it. And since video torrents are unzipped, a single chunk can be replaced with the malicious chunk with the attack code. It can look like a tiny jitter depending on the chunk size/total video size.

You could just do this with a video you release anyways, and skip the century of GPU runtime. This break requires you control/generate both the original and the evil file.

My thought exactly, although you would need your malware to incubate for some time to allow it to spread properly first.

Re: Announcing the first SHA-1 collision

#153

Post by mtgx »

Never forget: when Facebook, Twitter, and Cloudflare tried to slow-down SHA-1 deprecation:

https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/...

https://blog.twitter.com/2015/sunsetting-sha-1

https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...

I think Microsoft tried to do it too early on, but eventually agreed to a more aggressive timeline.

Re: Announcing the first SHA-1 collision

#154

Post by comboy »

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…

I wonder if SHA1 was used instead of SHA256 for Bitcoin mining, how much optimization these SHA1 discoveries would bring to the mining process (since it's more like partial brute forcing rather than finding collisions) i.e. what would be the percentage difference in the difficulty because of them - on the long run, since it takes some time to implement those things as ASICs.

Re: Announcing the first SHA-1 collision

#155

Post by qznc »

korm wrote: post #82

[2012] Schneier - When Will We See Collisions for SHA-1? https://www.schneier.com/blog/archives/2012/10/when_will_we_... Pretty close in his estimation.

Schneier predicted "between 2018--2021 depending on resources". He explicitly says "Since this argument only takes into account commodity hardware and not [...] GPUs". Since Google used GPUs that very well explains the speedup to 2017.

Re: Announcing the first SHA-1 collision

#156

Post by Ajedi32 »

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 constraints of "one copy is malware free while the other isn't", which would be significantly more difficult (at least, as I understand it).

That said, I agree it's probably time for torrents to start moving to another hash function. With time and additional research, it's entirely possible that theoretical attacks like the one you described could eventually become practical.

Re: Announcing the first SHA-1 collision

#158

Post by Turbots »

espadrine wrote: post #110
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…

> the latest hot TV show in high def or whatever Since it takes 6,500 CPU years and 110 GPU years, it won't quite be the latest show, unless you have really deep pockets. There are way less costly ways to make money illegally using simpler vulnerabilities or by being a pay-to-use DDoS provider.

100,000 dollars to do the computation it seems, not that hard to get funding for if all the computers you infect can participate in your botnet once you do

Re: Announcing the first SHA-1 collision

#159

Post by antoinealb »

jnwatson wrote: post #142
antoinealb wrote: post #92

Earlier quoted context omitted.

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.

No. Signatures provide the same amount of integrity protection. In fact, all practical asymmetric signature schemes sign a hash. If an attacker can control what somebody signs, he can switch out signed documents using this vulnerability.

well I would say that if an attacker controls what you sign, your security model is already toast, isn't it ?
Post reply on HN