Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus on Git and SHA-1

plus.google.com

Post reply on HN
Print view View original

51–60 of 187 posts

Re: Linus on Git and SHA-1

#51

Post by colin_fraizer »

grzm wrote: post #48
colin_fraizer wrote: post #46

This, btw, is why we have e-cigarette bans. The fact that the generally high-IQ, paid-to-think-about-subtle-categorization community of software developers needs to be inoculated against the "I Heard SHA-1 Was Bad Now" meme, should serve as a reminder for why most things should not be managed by democracy. (Yeah, I know this will be read as a plea for monarchy and downvoted. It simply proves my point: people are WAY…

Save yourself some downvotes and remove the mention that you expect them.

Save myself from people proving my point? Why?

Re: Linus on Git and SHA-1

#52

Post by grzm »

colin_fraizer wrote: post #51
grzm wrote: post #48

Earlier quoted context omitted.

Save yourself some downvotes and remove the mention that you expect them.

Save myself from people proving my point? Why?

The HN guidelines specifically ask not to express the expectation of downvotes. You may be downvoted purely for ignoring the guidelines, regardless of the rest of your comment.

Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted.

https://news.ycombinator.com/newsguidelines.html

Re: Linus on Git and SHA-1

#53

Post by debatem1 »

vacri wrote: post #30
debatem1 wrote: post #11

I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move on. Super unprofessional.

Perhaps you should re-read the last paragraph of the article.

Can you explain why? I went back and reread it and it said the same thing I thought it did: that the fix wasn't a big deal and they were moving forward on it.

I agree it isn't a hairy fix, but think that it would have been better for everybody if it had been made before a SHA1 collision was found, as has been repeatedly proposed to Linus in the past. This would have avoided the entire discussion about SHA1 and git, and all the angst that went with it.

Re: Linus on Git and SHA-1

#54

Post by [deleted] »

vacri wrote: post #30
debatem1 wrote: post #11

I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move on. Super unprofessional.

Perhaps you should re-read the last paragraph of the article.

[deleted]

Re: Linus on Git and SHA-1

#55

Post by butwhynotmore »

In the specific case of cryptography where it's unknown how bulletproof the algorithm will be why not use multiple hash functions? Perhaps using the top 10 best hash functions of the day. That way you're not putting all your eggs in one basket and if nefarious collisions are able to be created in the future you still have the other hash functions to both "trust" and double check against. It's even more unlikely that nefarious collisions will be able to be constructed that collide all the other hash functions as well. You could just append the hashes to each other or put them in a hash table or something. Maybe my computer science is not up to snuff but it seems like this would provide more resiliency against future and non-public mathematical breakthroughs as well as increased computing power such as quantum computing. Yes, it would take a little longer to compute all the hashes in day to day use, but with the benefit of a more robust system both now and in the future.

Re: Linus on Git and SHA-1

#56

Post by simplehuman »

bascule wrote: post #3

Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…

> Linus just doesn't take this stuff seriously. I really wish he would, though.

Can't downvote this enough. This is plain FUD. Did you even read the complete thread on the git mailing list? This was just one proposal by him.

Re: Linus on Git and SHA-1

#57

Post by AgentME »

simplehuman wrote: post #56
bascule wrote: post #3

Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…

> Linus just doesn't take this stuff seriously. I really wish he would, though. Can't downvote this enough. This is plain FUD. Did you even read the complete thread on the git mailing list? This was just one proposal by him.

If he took this stuff seriously, he wouldn't have waited 12 years since SHA-1 was broken to even start considering any changes.

Re: Linus on Git and SHA-1

#58

Post by infinity0 »

bascule wrote: post #3

Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…

> "A hash that is used for security is basically a statement of trust [..] In contrast, in a project like git, the hash isn't used for "trust". I don't pull on peoples trees because they have a hash of a4d442663580. Our trust is in people, and then we end up having lots of technology measures in place to secure the actual data."

This is horseshit, and Linus should not be saying these hugely misleading statements about security principles.

The point of a hash is to remove the need for trust between the trusted person who tells you the hash and the infrastructure you get the actual data that was hashed, from (edit: and, between you and the latter).

In other words, once you get a good non-colliding hash from a trusted person, then you don't need to worry about malicious infrastructure sending you bad data claiming to be the source of that hash.

Linus trusting Tytso to sign the commit object that references the SHA-1 of the tree object, says nothing about whether the infrastructure served him the tree object correctly. Sure, he might also trust the infrastructure providers, but when he says "trusts people" it does not sound like that is what he means. And even if he trusts the infrastructure providers, with a good hash HE DOESN'T HAVE TO.

The "trust" wording is serious horseshit.

(edit: there is also the case of people downloading "linux" from random git repos in the future. Right now if you GPG-sign a commit or tag, it has SHA-1 references to the tree object underneath it. Once SHA-1 is more broken it basically means you shouldn't trust random git repos across the internet to give you good content, even if it's "signed by Linus".)

Re: Linus on Git and SHA-1

#59

Post by AgentME »

bascule wrote: post #23
chainsaw10 wrote: post #21

Earlier quoted context omitted.

> reversing commit hashes back into their contents Somewhat off topic, but is this actually possible? Given hashing is inherently lossy, I'm inclined to assume it's not possible for anything must longer than a password, but commits are text, which I suppose is low entropy per character, so I don't know.

Yes this is possible. It's called a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack It's computationally infeasible against most cryptographically secure hash functions. However, Grover's algorithm results in a sqrt(keyspace) reduction in security levels (effectively halving bit-sized security levels): https://en.wikipedia.org/wiki/Grover's_algorithm

A successful preimage attack against a cryptographic hash would most likely find you a different message that gets you the same hash. You wouldn't do a preimage attack to find what the original input to create a hash was. You would do a preimage attack to find a new input with the same hash so that you could pass this new input around claiming it was the original (and have any signatures for the old input be valid for your new input, etc).

Re: Linus on Git and SHA-1

#60

Post by colin_fraizer »

grzm wrote: post #52
colin_fraizer wrote: post #51

Earlier quoted context omitted.

Save myself from people proving my point? Why?

The HN guidelines specifically ask not to express the expectation of downvotes. You may be downvoted purely for ignoring the guidelines, regardless of the rest of your comment. Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted. https://news.ycombinator.com/newsguidelines.html

A generally reasonable guideline, but in this case, I am actually criticizing the tribalism that makes people rise to that bait.

It similarly leads to the discussion of how "I can't believe Linus is trying to defend SHA-1 when The Tribe already knows it is cryptographically 'bad'."

Post reply on HN