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

41–50 of 187 posts

Re: Linus on Git and SHA-1

#41

Post by bascule »

pedrocr wrote: post #36
bascule wrote: post #12

Earlier quoted context omitted.

Can you please link me to "the plan" then? I have been trying to follow some of the ML discussion and that was the last plan I saw him put forth, e.g.: https://marc.info/?l=git&m=148787047422954

By clicking "next in thread" in that very post you get Linus replying to himself with a non-truncating plan: https://marc.info/?l=git&m=148787163023435&w=2

Thanks for the link.

Re: snark, I did hit "next in thread" but managed to skim over that in his response.

But again, thanks anyway.

(Note: this still sounds more like spitballing than "the plan", but at least it's a step in the right direction)

Re: Linus on Git and SHA-1

#42

Post by stouset »

mappu wrote: post #35
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:…

>(Also: if he's going to truncate a hash, he use SHA-512, which will be faster on 64-bit platforms) BLAKE2 is faster still! It's also at least as secure as SHA-3, and produces any choice of output size up to 512bit.

I'm a fan of blake2, but SHA-2 is the conservative choice here given the sheer amount of cryptanalysis it's been subjected to.

Re: Linus on Git and SHA-1

#43

Post by runeks »

One thing SHA-256 has going for it is that millions can be made from finding pre-image weaknesses in it, because it's used in Bitcoin mining. If you could "figure out" SHA-256, and use it to take over Bitcoin mining, you'd make $2M the first 24 hours, at current rates. And if you play it wise, it could take a long time before anyone figure out what's going on.

With regards to market price for a successful attack, I don't think any hash function stands close to SHA-256. And for that reason I think it would be the right choice.

Re: Linus on Git and SHA-1

#44

Post by debatem1 »

cwbrandsma wrote: post #24
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.

What is the realistic worst case situation here? From what I understand, git uses SHA1 as a way of generating an id for a file, not for security. So two files might match up when they shouldn't? Is that it or is there more to this? Or is this a proverbial "since SHA1 is don't work over there, then it shouldn't be used anywhere under any circumstance" attack?

As Linus touches on in the article, SHA1 is used for signing in git. This is clearly a security function, and should not have depended on SHA1 for at least the last several years.

Additionally, the defense offered against substituting binary blobs essentially comes down to "well, the kernel doesn't do that". Respectfully, other projects do. Those users' concerns were not taken seriously until lots of unrelated users freaked out about SHA1 for bad reasons.

Regarding the worst case scenario, yeah, substituting one binary blob for a different one (say, in Google's AOSP git repo) would be the worst. Which isn't sky-is-falling bad, but would still be pretty ugly.

Re: Linus on Git and SHA-1

#45

Post by gkya »

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

If a repo contains binary blobs, especially executables, well, that's very bad practices right there. Also, how can somebody else modify a binary in a meaningful way and send a patch to it? How can you review a patch to a binary file before applying? I'd say that any sane project, especially if open source, would not include binaries (maybe apart from images), and even if it did, would not accept patches to them (if the members of a project were talking about changing, say, an icon, valid images would be exchanged on a mailing list/issue tracker, nobody would bother making, sending and applying binary diffs; then somebody w/ commit bit just commit it).

Let me put it more simply: if you're accepting patches for binary files in your repos you don't care about security at all. Maybe unless if you know how to decode machine code/JPEG manually.

Also, the proposition was to use the full hash internally, and truncate the representation. Nobody other than git itself uses full hashes anyways.

Re: Linus on Git and SHA-1

#46

Post by colin_fraizer »

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 too subject to errors in the classes (1) "I hate him because he said something 'bad' about something 'good'." and (2) "I hate him because he said something 'good' about something The Tribe now knows is 'bad.')

Re: Linus on Git and SHA-1

#47

Post by sigzero »

hermitdev wrote: post #37
hueving wrote: post #31

Earlier quoted context omitted.

What is this known vulnerable attack you are talking about? The birthday paradox applies to every hashing function.

While there may not be a known, direct, attack against git, WebKit's SVN repository was demonstrably attacked by the SHA-1 vulnerability, oddly by their own developers today (or yesterday?). That it took that little time from a PoC to an actual production issue leads me to believe it wouldn't take long for a dedicated individual or team to extend the vulnerability to git and it's "mitigation" involving the header. I…

Linus talked about all of this and why the way git works makes it even harder, supremely harder, to pull off. Nobody is taking the "bury my head" road and Linus talked about ways forward.

Re: Linus on Git and SHA-1

#48

Post by grzm »

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.

Re: Linus on Git and SHA-1

#49

Post by Dylan16807 »

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

- 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

What level is considered secure, then? The numbers for O(time) and O(space) should be many orders of magnitude apart to represent the relative costs.

Re: Linus on Git and SHA-1

#50

Post by debatem1 »

spatulon wrote: post #22
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.

"Unprofessional" is an odd choice of word. I cannot see what you mean. He explains why he wrote the post: "since the SHA1 collision attack was so prominently in the news." I think a lot of people on Hacker News and elsewhere are interested in both the SHA1 collision and how it affects git, even if it doesn't impact them. Still, even if this were some obscure bug that nobody cared about, what would be unprofessional a…

The issue is that this could have been fixed years ago. All the information needed to move forward today was also available the last time this got brought up. Fixing it then would have better for git's users (because they wouldn't have freaked out over this) and better for git (because it never would have even come up in the SHA1 discussion) and better for Linus (because he wouldn't have had to spend an hour writing a blog post about this). So why not do it then?

It's frustrating, because Linus clearly isn't stupid. And yet sometimes he does stuff like this where I can't help but go "how did you not see the unforced error you were making?".

Post reply on HN