Thread

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

570 points · 536 comments · chmaynard

GrantMoyer · 1790901367 · focus · HN ↗
For reference: <a href="https://git-scm.com/docs/hash-function-transition" rel="nofollow">https://git-scm.com/docs/hash-function-transition
Notably, a few of the featured author's reservations appear to be addressed. According to the Git docs:
- Objects can be referred to by their old, SHA-1 name or their new, SHA-256 name. This means old refs in docs and comments and such remain valid. The mapping between SHA-1 representations and SHA-256 representations appears to be intentionally bijective a.k.a. 1-to-1 (assuming no hash collisions), so that it could be re-computed on demand. The constraint of bijectivity appears to be the source of some limitations, ex. no mixed repos and submodules needing to match hash algroithm, but also bijectivity has strong benefits like the following items.
- A bi-directional dictionary is maitained from SHA-1 to SHA-256 names so translations between the two don't required re-hashing objects. This table could be recomputed on demand due to the bijection between names; it's only a performance optimization.
- A local SHA-256 converted repo (including an SHA-256 converted submodule) can interoperate with an SHA-1 only remote transparently to the remote server by translating names using the lookup table.
- SHA-1 based GPG signatures will be preserved. A commit can be signed based on its SHA-1 representation, its SHA-256 representation, both, or neither. The bijection means the two types of signatures are in a sense interchangeable, or in other words the bijection between object representations implies an equivalence relation on signatures. An SHA-256 converted repo can quickly validate an SHA-1 based gpg signature using the lookup table.
1. krupan · 1790958074 · focus · HN ↗
  If we are changing to sha256 because sha-1 is broken, how can we trust all those mappings and signatures?? This makes it even more confusing as to why this change is being made
  1. GrantMoyer · 1790963468 · focus · HN ↗
    Git moved to a modified SHA-1 (let's call it SHA-1′) back in 2017 which prevents the particular attack described in SHAttered, so the SHA-1′ object names and signatures can be trusted for now. But the known collision attack on the underlying algorithm makes it more likely for SHA-1′ to be broken in the future too. Researchers could find variations or improvements of the weaknesses used in SHAttered to attack SHA-1′ as well. In other words, there are no known practical collision attacks, but there are known avenues of reasearch that could lead to practical collision or second-preimage attacks being discovered.
    The idea, then, is to migrate all git history to a stronger hash before that happens. If we waited until an attack was found, it'd be too late; all git history would be suspect forever into the future (disregarding extensive auditing), even if a stronger hash was used retroactively. Full SHA-256 doesn't have known practical collision attacks, and it doesn't even have known research avenues likely to lead to practical collision attacks, so is considered more future-proof than SHA-1′.
    This idea of future-proofing is common in cryptography. For example RSA-1024 keys are now considered practical to factorize (with a supercomputing cluster and a few months), but that's okay, because, foreseeing the possibility, "everyone" switched to RSA-2048 or stronger a decade ago. Now we're adopting new key algorithms to protect against possible quantum computing attacks in the future.
    krupan · 1790965407 · focus · HN ↗
    Yes, I understand all that. The original author points out that completely ditching sha-1 will be a huge pain, very costly, and won't meaningfully improve security. You responded by saying we aren't completely ditching sha-1, which seems to lend credence to the argument that sha-1 is still safe enough to use. That's where I'm confused. Having two hashes for each object in a git repo, a sha-1 and a sha256, is not the same as wholesale deleting your rsa-1024 keys and replacing them with rsa-2048. If I'm only looking at the sha-1 and all my tools only look at that, then the sha256 isn't helping me. Is it?
    GrantMoyer · 1790972739 · focus · HN ↗
    Ah, the plan is to eventually completely ditch SHA-1, but only after "everyone" has already converted to SHA-256, which is hopefully before SHA-1′ is broken. See sections Object names on the command line and Transition plan from the link in my top-level comment.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.