Linus' reply on Git and SHA-1 collision • Hacker News Board

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

#271

Post by [deleted] » Sat, Feb 25, 2017, 9:19 PM UTC

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…

[deleted]

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

#272

Post by cben » Sun, Feb 26, 2017, 10:45 AM UTC

throwaway7767 wrote: post #190

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…

Another case where git uses SHA1 is submodules. You audit libfoo's well-regarded v1.3.3.7 release, commit badc00fee, decide it's suits your need and use that commit as a submodule in your project. You assume resolving the submodule will always give you same code (or fail).

Alas, libfoo author has been corrupted by The Adversary and later arranges for same hash to resolve to different code. (currently we're talking of collision not 2nd preimage, but libfoo's author could have been planning it all along, before your audit.)

["libfoo" here is fictional, I'm not refering to any of the projects actually named that.]

Similar things happen when Git hashes are exchanged by any side channel. The ability to use strong hashes as pointers to content inside any other data is the whole beauty of Merkle DAGs. Git submodules just happen to be one such channel that's part of git, but I think it's important to accept that git commit hashes are widely used outside git itself.

P.S. I see git-evtag already covers submodules. Nice.

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

#273

Post by icebraining » Mon, Feb 27, 2017, 9:15 AM UTC

jefurii wrote: post #259

Perseids wrote: post #182

Earlier quoted context omitted.

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

> 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. git-annex (written by Joey Hess from the email) is a way to manage binary blobs using Git, but IIRC it uses SHA256.

Yes, that's the default. It's configurable up and down, though (from SHA-1 to SHA-3).