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

431–440 of 524 posts

Re: Announcing the first SHA-1 collision

#431

Post by mysterydip »

pornel wrote: post #379
mysterydip wrote: post #355

Forgive my ignorance, but it seems a solution to collision worries is to just use two hashing algorithms instead of one. We have two factor authentication for logins, why not the equivalent for hashed things? Give me the sha1 and md5, rather than one or the other. Am I wrong in thinking even if one or both are broken individually, having both broken for the same data is an order of magnitude more complex?

You're effectively creating a new hashing algorithm, which is twice as long and twice as slow, and is built using constructs known to be weak.

Thanks, that makes sense.

Re: Announcing the first SHA-1 collision

#432

Post by hulahoof »

TheGrumpyBrit wrote: post #353
dwaltrip wrote: post #282

Earlier quoted context omitted.

This says more about the Bitcoin network than it does about the ease with which one can create a SHA-1 collision. From the article: Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total. 6,500 years of CPU computation for 1st phase of attack. 110 years of GPU computation for 2nd phase of attack.

It certainly raises an interesting question. The go-to response when anybody discusses brute forcing bitcoin is that the sheer number of possibilities makes finding a collision infinitesimally small. And that's true. Same for .onion certificates. But Google certainly haven't been attacking this for the last 6,500 years. With a sufficiently obscene amount of resources, it IS feasible to create an index of every possib…

I guess with their 2 year timeline they were using at least 3250x whatever they define as a standard CPU - I wouldn't be surprised if it was simply 3250 cores @ 2 years or an equivalent higher number and less time.

I'd be interested about the actual specs of the hardware if anyone see's that info pop up.

Re: Announcing the first SHA-1 collision

#434

Post by detaro »

bobbyyankou wrote: post #428

Can someone help me understand what the major distinction is between this accomplishment (SHAttered) and the same team's The SHAppening (2015)? It looks like the did the same thing or something similar in 2^57.5 SHA1 calculations back then versus 2^63 SHA1 calculations this time.

SHAppening was a freestart collision, this is a "full" one. This stack overflow answer looks like a good description of freestart collisions: https://crypto.stackexchange.com/questions/29695/what-is-a-f...

My attempt at TL;DR: SHA-1 works on blocks, and each block is processed and it's data "mixed" with a previous intermediate result based on the previous blocks (Merkle-Damgård construction). A freestart collision only shows blocks and values for the intermediate results which lead to a collision. For a full collision you still have to figure out what sequence of blocks gets the intermediate results to the necessary values.

Re: Announcing the first SHA-1 collision

#435

Post by paulddraper »

jeffdavis wrote: post #290

Does git have any path away from SHA1? I know the attack isn't practical today, but the writing is on the wall.

The writing has been on the wall for a long time, but Linus has been dead against it.

> And we should all digitally sign every single object too, and we should use 4096-bit PGP keys and unguessable passphrases that are at least 20 words in length. And we should then build a bunker 5 miles underground, encased in lead, so that somebody cannot flip a few bits with a ray-gun, and make us believe that the sha1's match when they don't. Oh, and we need to all wear aluminum propeller beanies to make sure that they don't use that ray-gun to make us do the modification _ourselves_.

He says it's not a security issue, so there are no "attacks" to protect against.

> the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.

I don't know how correct that is.

Re: Announcing the first SHA-1 collision

#436

Post by alephnil »

orasis wrote: post #362

" Today, 10 years after of SHA-1 was first introduced, we are announcing the first practical technique for generating a collision." Huh? It's been around a lot longer than 10 years.

SSL 3.0 uses it, and that was released in 1996, and sha-1 was released in 1995 as an improvment over md5 and sha-0. This means it is 22 years old.

Re: Announcing the first SHA-1 collision

#437

Post by spdustin »

nneonneo wrote: post #398
jwilk wrote: post #391

Earlier quoted context omitted.

Thanks! What tools did you use to analyse the JPEG?

I used Hachoir ( https://github.com/haypo/hachoir3 ), a Python library that I've contributed to. Hachoir disassembles files using a library of parsers, with the intent of describing the function of every single bit in the file. You can see the resulting disassemblies (rendered with the hachoir-wx GUI) here: http://imgur.com/a/F1cnV

Woah, that's a fascinating tool! What other sorts of things could Hachoir be used for?

Re: Announcing the first SHA-1 collision

#438

Post by [deleted] »

cesarb wrote: post #119

On a quick scroll of the comments, I haven't seen this posted so far: http://valerieaurora.org/hash.html We're at the "First collision found" stage, where the programmer reaction is "Gather around a co-worker's computer, comparing the colliding inputs and running the hash function on them", and the non-expert reaction is "Explain why a simple collision attack is still useless, it's really the second pre-image attack…

[deleted]

Re: Announcing the first SHA-1 collision

#439

Post by philipn »

korethr wrote: post #413

So, since Git uses SHA-1, does this mean we're going to see a new major version number of Git that uses SHA-2 or SHA-3 in a few years? I don't expect one overnight. For one, as noted, this is a collision attack, one which took a large scale of power to achieve. In light of that, I don't think the integrity of git repos is in immediate danger. So I don't think it'd be an immediate concern of the the Git devs. Secondly…

You can check out the git developer mailing list discussion here: https://public-inbox.org/git/20170223164306.spg2avxzukkggrpb...

My rough summary: given there is no known second-preimage attack on SHA1, this is not an immediate danger to Git security because of the way Git works. The Git developers do want to move to a non-SHA1 hash at some point in the future.

Linus, from thread:

"I think that's a no-brainer, and we do want to have a path to eventually move towards SHA3-256 or whatever.

But I'm very definitely arguing that the current attack doesn't actually sound like it really even _matters_, because it should be so easy to mitigate against."

Re: Announcing the first SHA-1 collision

#440

Post by philipn »

paulddraper wrote: post #435
jeffdavis wrote: post #290

Does git have any path away from SHA1? I know the attack isn't practical today, but the writing is on the wall.

The writing has been on the wall for a long time, but Linus has been dead against it. > And we should all digitally sign every single object too, and we should use 4096-bit PGP keys and unguessable passphrases that are at least 20 words in length. And we should then build a bunker 5 miles underground, encased in lead, so that somebody cannot flip a few bits with a ray-gun, and make us believe that the sha1's match wh…

At least in the current discussion, Linus says that eventually moving away from SHA1 in Git is a "no brainer," but that this announcement isn't a "sky is falling" moment. (e.g. https://public-inbox.org/git/CA+55aFz98r7NC_3BW_1HU9-0C-HcrF...)
Post reply on HN