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. 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:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Pine.LNX.4.58.0504291221250.1890...

      1. bawolff · 1790880417 · focus · HN ↗

         &gt; 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&#x27;s impractical to exploit, which I think everyone agrees with.

         It seems unlikely it will stay that way forever. Typically attacks get more efficient over time as researchers find improvements, not to mention computers getting better.

         In 2015 it was estimated to cost $100,000, now the estimate is down to $10,000. Where will it be in 2035?

         1. AlfeG · 1790883247 · focus · HN ↗

            Even if it costs zero to create. How do You force people to pull from Your repo?

            1. odo1242 · 1790925341 · focus · HN ↗

               In GitHub, fork networks are represented as one repo on disk (this is the main optimization that makes community pull requests possible at all). So you could fork a repo and then push an object with a hash collision to it to change a file in the original, in theory.

               (In practice this is harder, as the article mentions, because the new forged object would have to be a valid gzipped git object of the same length. And GitHub probably knows about this type of attack and might just, for example, prevent existing objects from being overwritten)

               1. Dylan16807 · 1790926676 · focus · HN ↗

                  You also have to trick the code git added to detect and block shattered-style attacks.

                  Still, eliminating the risk is a good idea.

Unofficial Hacker News client; not affiliated with Y Combinator.