Thread

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

570 points · 536 comments · chmaynard

kpcyrd · 1790876562 · focus · HN ↗
This article is full of mistakes and misleading claims:
1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix.
2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout.
3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.
1. schacon · 1790877053 · focus · HN ↗
  1) I link to the SHAttered paper, as well as Shambles. Git projects were not affected because it is an inefficient attack vector. I say it's impractical to exploit, which I think everyone agrees with.
  2) I specifically argue that even if both attacks were practical and cheap, it's still not the problem we should be focusing on.
  3) Have you read this email (that I linked to)? It is almost the same general message (20 years ago) that this blog post is. It literally goes though a theoretical object replacement attack and how dumb this scenario is and so SHA-1 is fine.
  <a href="https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/" rel="nofollow">https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.1890...
  1. onion2k · 1790922602 · focus · HN ↗
    I say it's impractical to exploit, which I think everyone agrees with.
    Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.
    The go-to example is Stuxnet. Some countries wanted to attack Iran's nuclear enrichment programme, so they spent 5 years developing a worm that used multiple zero day exploits to attack a specific controller in a specific model of gas centrifuge. Could Mythos write Stuxnet? Unlikely, but a knowledgable team with access to it could probably write it in a lot less than 5 years.
    'impractical' has very different values for different groups.
    michaelt · 1790934700 · focus · HN ↗
    > Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.
    In all the years since 2017, with all the orgs having huge GPU-filled data centers (and an interest in software security) has anyone demonstrated a real git collision?
    Some systems have other properties that mitigate or prevent second preimage attacks - for example when you get an SSL certificate, CAs randomise the serial number. So an attacker can’t choose the checksum of the data the CA signs. Perhaps something in the design of git is similar?
    tosapple · 1790948195 · focus · HN ↗
    'randomize' is possibly the wrong word, it could include some form of serialization/fingerprint.
    tialaramex · 1790950118 · focus · HN ↗
    No, it really is the correct word. They just pick a huge random number. There's no value in "serializing" or "fingerprinting" such a number. It has two purposes, we need it to be unique, and we need it to be random and because it's a huge number being random means it is unique so we are done.
    tosapple · 1790959938 · focus · HN ↗
    yeah i don't know as esoteric as it is it could be a referential index into a bitmask/seive for your key.
    there's a lot you can do behind the scenes with even a couple bits of... free space?
    the key should be enough of a unique id to not have to require this? see (hash). a separate linked 'randomized' unique identifier might be crazy man territory but i'm not lying... your 'weakened' key doesn't _need_ to be all zeros, just predictable eg. within a certain time frame, anything that can reduce the search space is dangerous.
    edit: it could contain an identifier for which hrng was used to produce it.
    tialaramex · 1790964903 · focus · HN ↗
    This feels like you either don't know why we require this or, perhaps even more weirdly, you do understand why we require this but you've concocted some elaborate conspiracy to justify that rather than accepting the obvious explanation.
    At some point "The world is actually ball shaped" just makes a lot more sense than the thousands of years of vast elaborate conspiracies to keep you from realising that there are Mole People whose underground civilisation is accessible from Antarctica. So in the hopes that it's the former (you just didn't understand), I shall endeavour to explain.
    The MD-series and SHA-1 and SHA-2 series of cryptographic checksums use what is called Merkle–Damgård construction which operates on fixed sized blocks of data. In this design if we can find a collision before a certain block, everything after that point will keep colliding. The converse doesn't work, there aren't suffix collisions which would work for any prefix, only prefix collisions which work for any suffix. In SHA-3 and newer hashes a "Sponge" construction is used, we just pour stuff into the sponge and only squeeze out a fixed-size hash at the end, so these "prefix" attacks would need to change the entire state of that sponge.
    An X.509 certificate's serial number is very, very early, before any of the information which can be chosen by the recipient. So by ensuring this number is entirely random we're making it impossible to construct information which results in a collision, the prefix for their input will be random so it's now impossible.
    This is a "defence in depth" strategy. The SHA-256 hashes used are believed to be fine, for the immediate future, but even if they were vulnerable to a prefix attack as we know SHA-1 is, the choice to have random serial numbers defends us anyway, the attack wouldn't work on certificates.
    tosapple · 1791004592 · focus · HN ↗
    [dead]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.