Linux 6.14 To Switch From SHA1 To SHA512 For Module Signing By Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    Linux 6.14 To Switch From SHA1 To SHA512 For Module Signing By Default

    Phoronix: Linux 6.14 To Switch From SHA1 To SHA512 For Module Signing By Default

    While many Linux distribution vendor kernels are already using SHA-512 for signing modules by default rather than the default SHA-1, the upstream Linux 6.14 kernel is also now switching the default over to using SHA-512 for better security...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • KernelCrasher
    Junior Member
    • Feb 2024
    • 24

    #2
    Poly1305 should've been chosen instead. Much shorter, much faster and equally secure.

    Comment

    • stormcrow
      Senior Member
      • Jul 2017
      • 1518

      #3
      Should I have to say this in 2025? Hashing algorithms like SHA aren't for signing files. They are for hashing data to prove data integrity. A hash merely states this data is unaltered from its original production. It does not prove, and cannot prove, provenance. That's what signing does. Signing systems like PGP not only provide file integrity checks, but also prove the provenance of that file is from whom it claims to be. That's what secure boot theoretically is meant to reasonably prove. One of these things is not at all like the other.

      What little security aspect there is to hashing is a side effect of the theoretical ideal that unique data pushed through a hashing function should have a unique result. The reason to move to progressively more resource intense algorithms is because in the real world we haven't discovered a hashing algorithm that generates unique results for all input, hence the possibility of hash collision between two different sets of data. This means that integrity can not be completely guaranteed in all cases. Practical guarantees are a different matter and more subjective in nature based on risk acceptance. However, there's nothing at all that stops an attacker from regenerating hashed malicious modules in place of the intended modulesif the files have no cryptographic signature and some method of verifying that signature before the files are utilized.

      Addendum: For the extra paranoid: both signing and hashing processes are inherently racey. That means an attacker can at least theoretically pull a switcharoo before the algorithms are initiated, thus negating the provenance guarantee as well as hashing the wrong data. From a practical point of view, this isn't an attack scenario most people need contemplate. But on the other hand, how do you know you're not the target of a well resourced entity? You can't know till it's too late if you've said, done something, or part of a targeted project/group.
      Last edited by stormcrow; 27 January 2025, 05:37 AM.

      Comment

      • archkde
        Senior Member
        • May 2019
        • 691

        #4
        Originally posted by stormcrow View Post
        Should I have to say this in 2025? Hashing algorithms like SHA aren't for signing files. They are for hashing data to prove data integrity. A hash merely states this data is unaltered from its original production. It does not prove, and cannot prove, provenance. That's what signing does. Signing systems like PGP not only provide file integrity checks, but also prove the provenance of that file is from whom it claims to be. That's what secure boot theoretically is meant to reasonably prove. One of these things is not at all like the other.
        While a hash is not itself a signature, most signature schemes involve a hash function in their construction. The reason is that the underlying signing primitives only support a limited amount of data, so you have to reduce the input to a fixed size, which a cryptographic hash function achieves without compromising the security of the whole scheme.

        Comment

        • FrozenPie
          Junior Member
          • Jun 2024
          • 1

          #5
          Personally I prefer Blake3 as a hashing algorithm where it's possible as it hits the right balance of security, feature set and speed (nearly infinite parallelization) in my opinion. Sadly it was too late for the SHA-3 competition.

          Comment

          • EphemeralEft
            Senior Member
            • Dec 2022
            • 351

            #6
            Originally posted by archkde View Post

            While a hash is not itself a signature, most signature schemes involve a hash function in their construction. The reason is that the underlying signing primitives only support a limited amount of data, so you have to reduce the input to a fixed size, which a cryptographic hash function achieves without compromising the security of the whole scheme.
            +1

            Michael I miss the like button.

            Comment

            • EphemeralEft
              Senior Member
              • Dec 2022
              • 351

              #7
              Why not SHA256?

              Comment

              • AdrianBc
                Senior Member
                • Nov 2015
                • 299

                #8
                Originally posted by FrozenPie View Post
                Personally I prefer Blake3 as a hashing algorithm where it's possible as it hits the right balance of security, feature set and speed (nearly infinite parallelization) in my opinion. Sadly it was too late for the SHA-3 competition.

                BLAKE3 is nice, but it is an alternative only to SHA-256 (i.e. with 128-bit strength).

                Only BLAKE2b-512, which is slower than BLAKE3, is an alternative to the SHA-512 hash algorithm mentioned in this article.

                BLAKE3 has not been designed to satisfy all the requirements requested for SHA-3, so, as it is, it could not have participated in the competition. Of course, if it had been designed before the competition, it could have been easily extended to cover all the applications for which BLAKE2 had been designed, in order to enter the SHA-3 competition.

                The SHA-3 hashing algorithm also has variants that are exactly as parallelizable and as fast as BLAKE3. Unfortunately they are not included in the SHA-3 standard, because they have been developed after the competition, around the same time when BLAKE3 has been developed from BLAKE2.

                Only the older algorithms like SHA-256 or SHA-512, which are based on the obsolete Merkle–Damgård construction, cannot be parallelized.

                The real advantage of BLAKE3 over alternatives is not that the algorithm is intrinsically better, but that a high-quality multi-threaded implementation is available, which can be easily downloaded, installed and used by anyone, without effort.

                Some alternative hashing algorithms are also available in open-source libraries, but they may require more programming competence in order to be usable in a complete application.

                The Intel Arrow Lake S and Lunar Lake CPUs have hardware support for computing SHA-512. Presumably all future Intel and AMD CPUs will have such support. Many recent ARM CPUs also have hardware support for computing SHA-512. On such CPUs, using a tree hash like BLAKE3 can divide the time of hash computation by multiplying the power consumption with at least the same factor, but the computation of the tree hash will always require a much greater energy consumption than for computing a hash algorithm supported in hardware.
                Last edited by AdrianBc; 27 January 2025, 11:24 AM.

                Comment

                • Anux
                  Senior Member
                  • Nov 2021
                  • 1960

                  #9
                  Originally posted by FrozenPie View Post
                  Personally I prefer Blake3 as a hashing algorithm where it's possible as it hits the right balance of security, feature set and speed (nearly infinite parallelization) in my opinion. Sadly it was too late for the SHA-3 competition.
                  That sounds like a design flaw, if it is able to be highly parallel then it is also easy to brute force.

                  Comment

                  • AdrianBc
                    Senior Member
                    • Nov 2015
                    • 299

                    #10
                    Originally posted by Anux View Post
                    That sounds like a design flaw, if it is able to be highly parallel then it is also easy to brute force.
                    Nope.

                    For brute force, it does not matter whether hashing can be parallelized when computing a single hash.

                    Computing a great number of hashes, like in brute forcing, can be trivially parallelized regardless of the details of the hash algorithm.


                    Comment

                    Working...
                    X