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

Linus' reply on Git and SHA-1 collision

marc.info

Post reply on HN
Print view View original

181–190 of 273 posts

Re: Linus' reply on Git and SHA-1 collision

#181

Post by throwayguestman »

xkxx wrote: post #80
braveo wrote: post #65

Earlier quoted context omitted.

What's shocking is how badly people understand the purpose of an analogy. It's to communicate an idea to another person in a way that can also convey subtleties, and not just the literal words being conveyed. In this case, he was trying to convey the idea that the risk is so small and so remote that it really isn't worth spending a lot of time on. You understood the point, I understood the point, and everyone else un…

> What's shocking is how badly people understand the purpose of an analogy. The purpose of an analogy is to simplify something that's too hard to understand for the person you try to convey your idea to. Sometimes analogies are appropriate, e.g. when you teach something. When you want to convince somebody whose opinion is very different from yours, analogies aren't appropriate. They sound condescending: "because you…

>The purpose of an analogy is to simplify something that's too hard to understand for the person you try to convey your idea to

An analogy applies a principle to a common setting without loss of specificity. Specifically the dedicated adversary is lost in this abstraction, so it's a bad analogy.

Re: Linus' reply on Git and SHA-1 collision

#182

Post by Perseids »

notfed wrote: post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

I don't like the living-on-the-edge-attitude that Linus and others here promote regarding Sha1 in git. First, attacks only get faster over time. What costs millions today is likely to be achievable on commodity hardware in the coming years. Second, attacks only get more flexible over time. A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]. Third, devising an update strategy and rolling it out takes time. I can't guess how much hardwired use of Sha1 is in Github.

Fourth, people use git in creative ways. Linus may think it is a cardinal sin to commit binary blobs in a git repository, but I can't imagine I'm the only one using git as a poor man's backup and file sharing solution.

And last but not least, relying on Sha1 takes effort of constantly asserting its use in Git is still secure. Support request to that end will skyrocket from now on, both of the constructive kind, like the technically concerned coworker ("but isn't git insecure now that Sha1 is broken"), and of the regulatory kind ("if you use Sha1, MD5, … please fill out these extra forms explaining why your process is still eligible for certification with ISO norm foobar").

Since we have to migrate away from Sha1 at some point in the future, I'd like it to be sooner rather than later.

[1] See Wikipedia for a timeline and references: https://en.wikipedia.org/wiki/MD5#History_and_cryptanalysis

Re: Linus' reply on Git and SHA-1 collision

#183

Post by amingilani »

dozzie wrote: post #141
amingilani wrote: post #138

Earlier quoted context omitted.

Package managers allow you to download from git repositories too. He'd suffer from the same attack vector.

Erm... Which ones?

Almost all of them:

Npm: https://docs.npmjs.com/cli/install

Bundler: https://bundler.io/git.html

Homebrew: https://github.com/Homebrew/brew

Re: Linus' reply on Git and SHA-1 collision

#184

Post by throwayguestman »

dozzie wrote: post #166
throwayguestman wrote: post #158

Earlier quoted context omitted.

So, the problem still stands, theoretically. Not only do you likely need to populate your host with packages not from your host. But also, your host will also still be connect to a public net, even if only indirectly (e.g. private net), and hence potentially manipulated.

No, you misunderstood what is actually the problem here. Pulling under deployment some code from random resource from the internets that can go down or get deleted at a whim and you can't easily move to just some other mirror and you don't even control when the thing will be up back, that's the problem. Not the trust you need to put to use the code (this is still there, obviously). And the very same comment applies t…

I do understand, but "the trust you need to put to use the code" is what we were talking about, no?

Re: Linus' reply on Git and SHA-1 collision

#185

Post by throwmenow_0140 »

Perseids wrote: post #149
uiri wrote: post #112

Earlier quoted context omitted.

Wow, Linus raises an entirely different issue which is that the PDF-based attack won't work on git at all . Due to length prefixing, it is extremely difficult to insert nonsense into the middle of a git object which is how this attack works on PDFs. Linus correctly notes that using the first forty bytes of SHA-256 is an option if an attack against git's use of SHA1 were developed. 1) Git doesn't rely on SHA-1 for sec…

> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs. Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the sa…

  >>> len('''> Wow, Linus raises an entirely different issue which is that the PDF-based attack can't and won't work on git at all. Due to length prefixing it is extremely difficult to insert some nonsense into the middle of a git object which is how this attack works on PDFs.''')
  264
  >>> len('''Please note that the shattered-{1,2}.pdf files both have exactly the same length. And even with cleartext it is easy to pad passages so they contain the same amount of bytes. See how the quoted paragraph above has exactly the same number of characters as this one.''')
  264

Re: Linus' reply on Git and SHA-1 collision

#186

Post by hvidgaard »

Nutomic wrote: post #180
hvidgaard wrote: post #140

Earlier quoted context omitted.

That is jerry rigging it. If a stronger hash function is known to be secure, you throw all that confidence out the window if you truncate it. At best you reduce the brute force complexity, at worst you enable pre-image attacks.

This is wrong. There is no faster way for preimage attacks with truncated SHA-2. http://crypto.stackexchange.com/questions/9435/is-truncating...

I never said that, at all. I explicitely say

  At best you reduce the brute force complexity, at worst you enable pre-image attacks.
One thing I hate about crypto talk is statements like this

  So, truncating one of the SHA-2 functions to 160 bits is around 2^20 times stronger when it comes to collision resistance.
Which is all too broad. What if SHA-1 is down to 2^10, is truncated SHA-2 2^30? Does it mean we have proved that no weakness exist in SHA-2? A correct statement would simply be that no known attack exists on truncated SHA-2 yet.

Re: Linus' reply on Git and SHA-1 collision

#187

Post by CJefferson »

moonshinefe wrote: post #157

Correct me if I'm wrong, but if you're letting untrusted people push to your git repositories, you're pretty much screwed anyway. Given a case where someone with permission to push gets compromised and a malicious actor can pull this sha-1 attack off, aren't there bigger problems at hand? The history will be there and detectable or if they're rewriting history, usually that's pretty noticeable too. I may be totally m…

The problem is I can't now download a git repository from someone I don't trust, verify it is correct, and then publish "I, Chris Jefferson, trust git commit abc125.... is good.". Now I would have to be sure everyone who has ever committed to that git repository wasn't trying to do something dodgy.

I have put git commits into scripts I run on automated servers for example, to be sure that every server runs exactly the same copy of the program.

Re: Linus' reply on Git and SHA-1 collision

#188

Post by Perseids »

raverbashing wrote: post #160
Perseids wrote: post #142

Earlier quoted context omitted.

> There is no way to securely deploy a package directly from the internet. Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when…

apt-get can (and do) check signatures of repos But yeah, you could put an unverified repos to be used

For the argument at hand (Can you deploy anything on a production server from a third party that is only verified cryptographically?) signatures and hashes fulfill the same function (and btw I also wrote "verifying it against a hash or signature" above). More to the point, under the hood GPG signatures only sign a hash of the file in question anyway. Verifying a file via a GPG signature is strictly less secure than verifying it by its hash (assuming you use the same hash function as the signature).

Re: Linus' reply on Git and SHA-1 collision

#189

Post by throwayguestman »

braveo wrote: post #65
zkms wrote: post #21

Earlier quoted context omitted.

> "what if a meteorite hit my plane while it was in flight - maybe I should add three inches of high-tension armored steel around the plane, so that my passengers would be protected" I think this is a shockingly good example of how smart people get security questions utterly wrong. The right analogy when it comes to security has to involve some type of adversary, not just random, unmotivated natural phenomena -- as l…

What's shocking is how badly people understand the purpose of an analogy. It's to communicate an idea to another person in a way that can also convey subtleties, and not just the literal words being conveyed. In this case, he was trying to convey the idea that the risk is so small and so remote that it really isn't worth spending a lot of time on. You understood the point, I understood the point, and everyone else un…

> Which means the analogy was successful.

Sure, if he's saying he is powerless against higher powers. But if he's trying to make a quantitative assertion, a qualitative analogy is not the right tool.

Re: Linus' reply on Git and SHA-1 collision

#190

Post by throwaway7767 »

notfed wrote: post #56

Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…

> 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust.

Some security-focused developers sign git tags and/or commits, specifically to have things verifiable end-to-end and not having to trust HTTPS and all the middle men that entails.

Would that not be a case where git relies on SHA1 for security? Someone could replace a tag or commit with a malicious version that verifies fine since it has the same hash the original developer signed.

> 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's objects, they'd still have to convince you pull from their repo. This requires trust.

In the case of signed commits/tags, this opens projects up to malicious action by hosting companies and others. Usually signed commits and tags are used specifically to avoid that exposure, because the developers don't trust the infrastructure.

> 4) Even if you pulled it in, your git client would simply ignore their "poison" object, because it would say, "oh, no thanks, I already have that object". At worst, the code simply wouldn't work. No harm would be done.

That only protects existing checkouts that already have fetched that commit. What about new checkouts, or older checkouts that haven't been updated yet?

Not disputing that this SHA1 collision does not signal any immediate emergency, just pointing out that git is used in different ways by different people, and some of those uses very much do depend on git's SHA1 for security.

Post reply on HN