Live data from Hacker News

Linus on Git and SHA-1

plus.google.com

111–120 of 187 posts

Re: Linus on Git and SHA-1

#111

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

Not really. From Linus — I think the most important point that has not been discussed extensively:

> But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

Re: Linus on Git and SHA-1

#112
post #65

Earlier quoted context omitted.

If you are taking the view that you're expecting downvotes to prove the point that people who are trying to uphold community standards are doing so blindly or ignorantly, you'll very likely think you're proven correct when you do receive downvotes. Can you blame them? You're explicitly flaunting the guidelines they choose to abide by while telling them they're wrong to do so in your special case .

ahem... "flouting"

You're right, of course. Thanks!

Re: Linus on Git and SHA-1

#113
post #88

Earlier quoted context omitted.

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

You're saying Linus's statements are "hugely misleading", but it's just that you wish git were designed to be used differently. So, your argument is "horseshit". Linus could have designed a cryptographically perfect system such that he could pull Tytso's signed commit from anywhere on the internet - but he didn't Linus used sha1 as a useful tool for an effective DVCS with an initially simple implementation. He still…

> How could any of us have trusted any source code before 2005?! Somehow we did, though...

They used pgp to sign the tar ball, which was a way better idea since you could just use a different hash function for your signature after sha1 has been broken in 2005[1].

Everybody serious about security kept doing that, since signed git commits were just asking for trouble due to the hard dependency on sha1.

[1]: https://www.schneier.com/blog/archives/2005/02/sha1_broken.h...

Re: Linus on Git and SHA-1

#114
post #107

Earlier quoted context omitted.

If you feel CRC64 does not meet the requirements, use CRC128. For what it's worth, I think CRC64 should be fine for git-like workloads (but would still recommend using a cryptographically secure hash function, because git's usage is security-critical despite Linus constantly insisting it's not).

Why would you do that? Even if you don't know exactly what you want, are wrong about whether it's the basis of 'trust', for the purposes of writing git, you'd just take SHA-1. Nothing terrible is going to happen if it's both overkill and you aren't really building a secure system. You seem to be arguing, if I'm understanding you right, that you should only use a cryptographically strong hash iff you need all its prop…

I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp.

It is not an "odd angle". It is literally the very purpose for which they were created in the first place: to defend against attacks (preimage, collision)

If there are no attackers, the cryptography buys you nothing and merely makes the system slower.

Again, to go back to the original point: Linus's argument is that cryptographic functions have unique properties that make them specifically useful in non-security contexts. He's wrong. They don't. The non-cryptographic constructions he namedropped then glossed over work fine in these contexts.

Re: Linus on Git and SHA-1

#115
post #111

I don't really get the threat model here. If an attacker is pushing commits into your repository, you're long since toast on all possible security fronts, right? Is there anything nefarious they could accomplish through hash collisions that couldn't be done simply by editing commit history?

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

Well, open source software like Linux kernel has many obvious bugs for years go without notice. But his point is still extremely fair. There may be code no one really actively updating, but to even able to add random odd crud in the source code is really really really really hard. The effort is not worth it for any reasonable attackers. One would rather exploit an existing zero day or just infect network and wait to activate the infection. If someone modifies the local source code you just git cloned (or from a tarball), well you have something to worry about - your network.

Re: Linus on Git and SHA-1

#116
post #88

Earlier quoted context omitted.

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

You're saying Linus's statements are "hugely misleading", but it's just that you wish git were designed to be used differently. So, your argument is "horseshit". Linus could have designed a cryptographically perfect system such that he could pull Tytso's signed commit from anywhere on the internet - but he didn't Linus used sha1 as a useful tool for an effective DVCS with an initially simple implementation. He still…

"Finally, no well-known SCM previous to git was based on perfect cryptographic proof of source history, or anything like that."

This is actually false. Monotone, from which git takes a lot of cues (ask linus, or see wikipedia), was such a system.

Re: Linus on Git and SHA-1

#118
post #107

Earlier quoted context omitted.

Why would you do that? Even if you don't know exactly what you want, are wrong about whether it's the basis of 'trust', for the purposes of writing git, you'd just take SHA-1. Nothing terrible is going to happen if it's both overkill and you aren't really building a secure system. You seem to be arguing, if I'm understanding you right, that you should only use a cryptographically strong hash iff you need all its prop…

I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp. It is not an "odd angle". It is literally the very purpose for which they were created in the first place: to defend against attacks (preimage, collision) If there are no attackers, the cryptography buys you nothing and merely makes the system slower. Again, to go back…

I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp.

Well, if we're going to be dicks to each other about it I'll try to explain what I think appears to be difficult for you to grasp. :) If you were throwing together something like git in a hurry you'd want a hash that

Lets you not have to think about collisions at all even if:

The collisions are by mere chance

The collisions arise by non-malicious accident

The collisions arise from malicious inputs [obviously, that implies an attacker but it also falls under 'I just don't want to think about collisions']

And right there, you grab the first non-completely-broken, not-too-giant, not-too-slow crypto hash around and get on with whatever else you had in mind. And this, to me, seems like the right call, especially since if collisions did eventually pop up, it'll probably be one generative collision and your entire system won't suddenly implode just because it exists. You'll have some time to fix stuff.

Again, to go back to the original point: Linus's argument is that cryptographic functions have unique properties that make them specifically useful in non-security contexts. He's wrong. They don't. The non-cryptographic constructions he namedropped then glossed over work fine in these contexts.

No argument there. Maybe I misunderstood 'Linus said something wrong' as 'Linus did something horribly wrong' and we're arguing over nothing?

Re: Linus on Git and SHA-1

#119
post #43

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

https://twitter.com/veorq/status/834872988445065218

I think the claim is interesting, and I certainly wouldn't reject it. But just relaying someone else's claim, without any substantiating argument, I find quite uninteresting.

Re: Linus on Git and SHA-1

#120
post #111

Earlier quoted context omitted.

Not really. From Linus — I think the most important point that has not been discussed extensively: > But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

Well, open source software like Linux kernel has many obvious bugs for years go without notice. But his point is still extremely fair. There may be code no one really actively updating, but to even able to add random odd crud in the source code is really really really really hard. The effort is not worth it for any reasonable attackers. One would rather exploit an existing zero day or just infect network and wait to…

The kernel, and OpenSSH to name another project, is full of random crud nobody noticed. Everyone does their best to review patches and ensure things are sane when going in, but there's a lot of change in projects at scale, and sometimes the standards one patch wrangler has are different from another. Mistakes happen.

If at-patch time is your only code review, you've got problems. If your code base is too huge to look over frequently you've got problems.

Post reply on HN