Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

meinersbur · 1790878728 · focus · HN ↗
Linus Torvalds in 2007:
> but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, Okay, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get. ... [1]
[1] <a href="https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s" rel="nofollow">https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
So Torvalds used SHA-1 purely because he needed a hash function with no other property than identifying content.
1. zamalek · 1790879278 · focus · HN ↗
  Exactly. But that's why I think SHA was a mistake. He should have gone with something like murmur to avoid all this frothing at the mouth.
  1. kazinator · 1790879572 · focus · HN ↗
    Frothers gonna froth, though.
  2. huflungdung · 1790880198 · focus · HN ↗
    [dead]
  3. bawolff · 1790880480 · focus · HN ↗
    If that was true, i doubt git would have switched to using the slower version of sha-1 that detects attacks.
  4. Someone · 1790883791 · focus · HN ↗
    Linus, in 2005, couldn’t have gone for murmur, from 2008.
    Was there “something like murmur” in 2005 that’s cryptographically better than SHA1?
    sgerenser · 1790894620 · focus · HN ↗
    Yeah, in 2005, SHA-1 was just about the best you can do given the constraints of the time (without picking something much more esoteric, much slower, etc.). Using SHA-256 at that time would have been noticeably slower on the computers of the time, and made repo metadata take up a lot more space.
  5. layer8 · 1790884826 · focus · HN ↗
    It was a mistake to assume a fixed algorithm in the repository format and client-server protocol. I remember being surprised when I learned about that choice, being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.
    throw0101c · 1790887224 · focus · HN ↗
    > It was a mistake to assume a fixed algorithm in the repository format and client-server protocol.
    See also perhaps Wireguard, which touts itself as not having "cryptographic agility" because they wanted to avoid all (perceived) problems and complications of IPsec. But now that PQC is (allegedly) approaching there's no easy to update things because (AIUI) there's no negotiation possible in the protocol; you're basically standing up a 'Wireguard 2.0' that runs separately than the original.
    akerl_ · 1790903919 · focus · HN ↗
    That is in fact the idea, and was on purpose.
    someonebaggy · 1790914520 · focus · HN ↗
    Which is fine, for wireguard which only encrypts things ephemerally.
    computerfriend · 1790916315 · focus · HN ↗
    Wireguard is secure against a quantum computer though, via an additional pre-shared key.
    > If an additional layer of symmetric-key crypto is required (for, say, post-quantum resistance), WireGuard also supports an optional pre-shared key that is mixed into the public key cryptography.
    (From <a href="https://www.wireguard.com/protocol/" rel="nofollow">https://www.wireguard.com/protocol/.)
    loeg · 1790899233 · focus · HN ↗
    > being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.
    This flexibility ("agility") in cryptographic protocols is often seen as a mistake today, actually.
    WorldMaker · 1790906268 · focus · HN ↗
    Cryptographic protocols have been moving towards something of a compromise in flexibility. "Everything flexible" is a security risk, especially when "everything" includes "fallback to nothing secure". "No flexibility" is a security risk because you can't upgrade. The middle path is something like "version numbers" with hard breakpoints. "I only support v2 of this cryptographic protocol and will not fallback to v1."
    Which is sort of the hash algorithm approach git is taking with incompatible versions and a version break.
    layer8 · 1790924680 · focus · HN ↗
    No, the mistake is to not restrict the allowed algorithm suites in a given deployment and in default configurations. However, for the allowed algorithms to be able to change over time, algorithm agility is needed. For example, the migration from RSA to ECDSA (and variants) to PQC algorithms, and from smaller to larger key sizes, would be vastly more difficult without algorithm agility.
    All modern formats, such as JOSE and COSE, continue to be built on algorithm agility, and that’s unlikely to change.
    Older protocol elements that had SHA-1 or SHA-256 hardcoded have invariably been replaced or supplemented with elements using an algorithm parameter.
    throwawayffffas · 1790907257 · focus · HN ↗
    1. As others have noted, flexibility in cryptographic protocols is generally a mistake.
    2. The hash function is not used for cryptographic purposes!
  6. m463 · 1790965086 · focus · HN ↗
    didn't he create git in like a weekend?
2. UltraSane · 1790902904 · focus · HN ↗
  Hard coding a specific hash algorithm was a big mistake.
  1. someonebaggy · 1790941534 · focus · HN ↗
    Have you seen algorithm-agnostic protocols, like TLS v1.2 and IPsec? It always turns out to be a bad idea. Future upgradability is fine but you really don't want implementations of the protocol to be incompatible with each other and you don't want attackers to have any chance of tricking you to using insecure protocols.
    Flexibility made sense in 1995 when nobody was sure which algorithms would stand the test of time. Even in 2005 it was unnecessary and in 2015 it was an outright liability. If you have a good algorithm just specify the good algorithm, don't let the parties negotiate either a good one or a bad one.
    UltraSane · 1790969973 · focus · HN ↗
    Your argument is weird because it assumes we can know if a hash function will be secure forever. Assuming git would use SHA1 forever seems shortsighted.
    someonebaggy · 1791039323 · focus · HN ↗
    Then you make Git 2, which uses SHA256.
    UltraSane · 1791042368 · focus · HN ↗
    That creates even more compatibility issues for no reason.
3. creata · 1790907291 · focus · HN ↗
  > It's purely a consistency check. The security parts are elsewhere
  Sorry if the video answers this, but how does commit signing work if it doesn't rely on the hash algorithm being resistant to at least second-preimage attacks?
  1. someonebaggy · 1790914467 · focus · HN ↗
    Things changed since 2007
    xeyownt · 1790938682 · focus · HN ↗
    How they changed?
    For all practical purpose SHA-1 is a bad hash function, it's slow, it's insecure.
    If SHA-1 is not a security measure, why do you even sign the commit. It doesn't make any sense. You give a strong signature on something weak.
    someonebaggy · 1790940619 · focus · HN ↗
    Well they didn't sign commits in 2007, and there wasn't github in 2007, so it wasn't a security measure in 2007.
    albedoa · 1790954481 · focus · HN ↗
    Buddy, you are naming the things that changed.
    creata · 1790955260 · focus · HN ↗
    Thanks. (More detail: Git added signed commits in Git 1.7.9, which was released in 2012.)
4. mnaza · 1790924936 · focus · HN ↗
  That was true in 2007, but it stopped being true once people started signing commits and tags. A GPG/SSH signature on a commit covers the commit object, which names its tree and parents by SHA-1, so the signature is exactly as strong as SHA-1's collision resistance. If someone can prepare two trees with the same hash, a signed release tag vouches for both of them.
  SHA-1DC blocks the known SHAttered/Shambles-style attacks, which is a good stopgap, but it detects known techniques; it isn't a hash you can reason about.
  Code signing went through the same thing. Authenticode signatures with SHA-1 digests are effectively distrusted on Windows now, and that migration hurt precisely because it was put off until it was urgent.
5. hinkley · 1790931542 · focus · HN ↗
  Hmm, I swear he disagreed with this in a different talk. But maybe I’ve conflated a presentation by someone else with one of his.
6. lxgr · 1790946975 · focus · HN ↗
  It's of course possible that SHA-1 was not originally intended as a security feature, but according to Hyrum's law, every observable API behavior becomes something that somebody starts to depend on, so if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure.
  At the very latest, this fact was cemented when first-party git commit signatures started depending on the security properties of SHA-1.
  1. feoren · 1790953282 · focus · HN ↗
    > if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure
    So if my API happens to return text strings that always happen to have an even number of characters, I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that? No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.
    lxgr · 1790955465 · focus · HN ↗
    Hey, I'm just the messenger here, if you don't like it, take it up with Hyrum ;)
    But seriously: If you can afford to break your user's applications if they "deserve to be broken", sure. Many API maintainers can't, or at least don't want to.
    In the latter case (which is honestly the norm rather than the exception, at least for public APIs), yes, you should better think about all implicit API contracts your API shape might be projecting. That guideline has served me very well through my career, at least.
    tredre3 · 1790957862 · focus · HN ↗
    > No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.
    Just because you never made any promise regarding one aspect of your API doesn't mean that you're absolved from responsibility when you choose to change it. If you know for a fact that many users rely on it and you choose to break it, you need a good reason. That kind of balancing act is part of your job. If you don't respect your users, perhaps development wasn't the right career choice.
    As developers we're of course constantly tempted to rename things that we named poorly, or change a schema that is no longer optimal. But we must always take a step back and think about the downstream impact.
    cesarb · 1790958293 · focus · HN ↗
    > I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that?
    Oh yes, this does happen. There's even a name for that: ossification (<a href="https://en.wikipedia.org/wiki/Protocol_ossification" rel="nofollow">https://en.wikipedia.org/wiki/Protocol_ossification). You can't change your API/protocol, because "some moron" started depending on implementation details.
    It's easy to say "your application deserves to break" from an ivory tower, but it's often not easy or viable to fix it (for instance, it might have different owners, it might no longer be maintained, it might be more expensive to change, etc). And the change which broke that application was not in it; the blame naturally goes to what was changed last.
7. shubhamjain · 1790951922 · focus · HN ↗
  Linus is one of the last remaining champions of rationality in large-scale software projects. Otherwise, it’s filled with devs who love to leave their brains out when it comes to practical scenarios. Anyone who thinks there is a security issue here is an absolute moron.
  1. gaoshan · 1790954902 · focus · HN ↗
    Rationality is the key point. A lot of devs approach their work in ways that are not rational or practical. Like the dev who wants to build a gold filigree decorated elevator that can handle ten thousand pounds of cargo and moves with the smoothness of a magnetic levitation rail in order to reach the second floor when all you really need is a ladder for the 2 people that will need access.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.