Thread

1. 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:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;t=56m20s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;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&#x27;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. 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.

         1. throw0101c · 1790887224 · focus · HN ↗

            &gt; 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 &quot;cryptographic agility&quot; because they wanted to avoid all (perceived) problems and complications of IPsec. But now that PQC is (allegedly) approaching there&#x27;s no easy to update things because (AIUI) there&#x27;s no negotiation possible in the protocol; you&#x27;re basically standing up a &#x27;Wireguard 2.0&#x27; that runs separately than the original.

            1. akerl_ · 1790903919 · focus · HN ↗

               That is in fact the idea, and was on purpose.
            2. someonebaggy · 1790914520 · focus · HN ↗

               Which is fine, for wireguard which only encrypts things ephemerally.
            3. computerfriend · 1790916315 · focus · HN ↗

               Wireguard is secure against a quantum computer though, via an additional pre-shared key.

               &gt; 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:&#x2F;&#x2F;www.wireguard.com&#x2F;protocol&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wireguard.com&#x2F;protocol&#x2F;.)

         2. loeg · 1790899233 · focus · HN ↗

            &gt; being familiar with cryptographic protocols and formats where the hash algorithm is usually a parameter that can vary for each concrete hash.

            This flexibility (&quot;agility&quot;) in cryptographic protocols is often seen as a mistake today, actually.

            1. WorldMaker · 1790906268 · focus · HN ↗

               Cryptographic protocols have been moving towards something of a compromise in flexibility. &quot;Everything flexible&quot; is a security risk, especially when &quot;everything&quot; includes &quot;fallback to nothing secure&quot;. &quot;No flexibility&quot; is a security risk because you can&#x27;t upgrade. The middle path is something like &quot;version numbers&quot; with hard breakpoints. &quot;I only support v2 of this cryptographic protocol and will not fallback to v1.&quot;

               Which is sort of the hash algorithm approach git is taking with incompatible versions and a version break.

            2. 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.

         3. 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!

Unofficial Hacker News client; not affiliated with Y Combinator.