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

181–190 of 524 posts

Re: Announcing the first SHA-1 collision

#181

Post by Ajedi32 »

0xcde4c3db wrote: post #160

If you trust a signer, does this attack do anything to invalidate their SHA-1-based signatures? Or is the scenario strictly an attacker generating both versions of the message?

As I understand it the attacker would have to generate both versions of the message. If an attacker could generate a second message with a hash that matches that of an existing message from a third party, that would be a second-preimage attack, not merely a collision attack.

Even MD5 is still considered to be second-preimage resistant: http://crypto.stackexchange.com/q/3441/21238

Re: Announcing the first SHA-1 collision

#182

Post by mlonkibjuyhv »

svantana wrote: post #152
throwaway2048 wrote: post #145

Earlier quoted context omitted.

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.

I wonder if you could model this similarly to populations. As in will the malware ever go extinct? Obviously an attacker probably won't stop seeding, but let's say shim does stop seeding. At this point x% of seeders have the payload. Seeders on average share the file y times. Will x tend to zero below a threshold of 50%?

And if the attacker does not stop seeding, will the infected quota stabilize?

Re: Announcing the first SHA-1 collision

#183

Post by koolba »

anilgulecha wrote: post #165
koolba wrote: post #81

Earlier quoted context omitted.

That's not an issue with the torrent. That would be with the magnet link format. Also, and more importantly, this isn't a preimage attack so replacing an existing torrent's SHA-1 hash with a malicious one isn't computational possible.

Magnet URI hash is SHA1. A hash collision can still be used as an attack if you create 2 torrents with the same hash and then distribute.

That's not an issue with the torrents. It's an issue with the magnet URI format for referncing torrents.

The "good" torrent would not be susceptible to attack via this receiving the entire torrent file directly (say over HTTPS) is fine.

Re: Announcing the first SHA-1 collision

#184

Post by mrb »

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…

"That said, attacks only get better"

In the case of MD5 collision research, initially it took a cluster of PS4 months to find one. But a few years later a laptop can find a collision instantaneously. So yeah, expect rapid improvement of SHA1 collision feasibility.

Re: Announcing the first SHA-1 collision

#185

Post by anilgulecha »

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.

Re: Announcing the first SHA-1 collision

#186

Post by mikeash »

Beltiras wrote: post #176
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?

In 90 days the team will release their PoC code and you can take a look.

But overuse of social media has left me with the attention span of a gnat!

Re: Announcing the first SHA-1 collision

#187

Post by Natanael_L »

Aissen wrote: post #169
sp332 wrote: post #129

Earlier quoted context omitted.

If you find a collision for the smallest piece, you don't need to find collisions for any higher nodes on the Merkle tree because you'll just be hashing the same values as the legit version.

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.

Re: Announcing the first SHA-1 collision

#188

Post by SadWebDeveloper »

It's still quite impractical, m sure with some quantum computer or a custom ASIC built by those "super nerds" at the NSA its possible but but for you general adversary aka "hackers" (skiddies IMHO) it will be infeasible.

What this means is for all of you [developers], is to start new projects without SHA1 and plan on migrating old ones (if it's totally necessary, normally don't unless you use SHA1 for passwords).

A Great resource for those who still don't know how or what hash to use, is paragonie: https://paragonie.com/blog/2016/02/how-safely-store-password...

Re: Announcing the first SHA-1 collision

#189

Post by alfalfasprout »

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 >…

Eh, at that point you may as well buy the servers yourself and let them run on-premises. Even with power, etc. that cost could easily come down 50% or more. Once you own the servers, additional tasks just cost power.
Post reply on HN