Thread

1. 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. alerighi · 1790951741 · focus · HN ↗

      You are basically resolving a non-existent security problem by generating a far bigger security problem, because I'm 100% sure that a ton of software just assumes that a git commit hash fits in a `char[40]` and thus will buffer overflow like hell if they try to operate on new repositories.

      And we are talking about who knows how many tools that work with git built in the years, and this is also made it worse from the fact that most tools just invoke the git binary and capture its output instead of passing from a library.

      I like more the solution proposed at the end of the article, do not change sha-1 but instead, if you are relying on git commit for security purposes (that was never the intended use) add another header to the git object with a sha-256, so that with the small expense of computing the hash twice you don't break 20 years of existing tools that make the assumption of the git commit being 40 character long.

      1. wongarsu · 1790953836 · focus · HN ↗

         I would have liked sha-256 truncated to 40 characters (by analogy to sha-512/256 that'd be sha-256/160). Cryptographically that's probably fine. But 160 bits is not a lot. And probably fine doesn't tend to inspire confidence in the field of cryptography. It's not a very well studied scheme

         An advantage of a hash with a different length is that a full length sha1 commit hash and a full-length sha256 commit hash can't be confused for each other

         1. stickfigure · 1790962951 · focus · HN ↗

            Except that git commands generally accept partial hashes...

Unofficial Hacker News client; not affiliated with Y Combinator.