Announcement

Collapse
No announcement yet.

BLAKE3 Cryptographic Hash Implementation Preparing For v1.0 Release

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BLAKE3 Cryptographic Hash Implementation Preparing For v1.0 Release

    Phoronix: BLAKE3 Cryptographic Hash Implementation Preparing For v1.0 Release

    The BLAKE3 high performance crypto hashing function that is much speedier than MD5, SHA-1/SHA-2/SHA-3, and the former BLAKE2, is nearing its v1.0 release for its official Rust and C implementations...

    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

  • #2
    Sure it's a little faster, but could you really pick this over SHA-512 for security applications? Possibly an interesting research area, but "no-one ever got fired for using the industry standard cryptography"

    Also do those benchmarks use SHA hashing features built into CPUs these days? If hashing were really my bottleneck that's the first thing I'd look at when picking my CPU architecture.

    Comment


    • #3
      Originally posted by OneTimeShot View Post
      Sure it's a little faster, but could you really pick this over SHA-512 for security applications?
      It's significantly faster, especially for long messages. You can pick SHA3-512 when speed does not matter and you have other requirements, or BLAKE2, which is still faster than the SHA alternatives and has also withstood lots of cryptanalysis. (And BLAKE3 shares the core hash function of BLAKE2, but it is used in a tree construction and has reduced number of rounds.)

      Originally posted by OneTimeShot View Post
      Possibly an interesting research area, but "no-one ever got fired for using the industry standard cryptography"
      Ahm, yes, they have. You can build completely insecure applications from "industry standard cryptography".

      Originally posted by OneTimeShot View Post
      Also do those benchmarks use SHA hashing features built into CPUs these days? If hashing were really my bottleneck that's the first thing I'd look at when picking my CPU architecture.
      Intel has broken SHA1 and SHA2-256 only instructions as far as I know and SHA2-256 is susceptible to length extension attacks, so you need to truncate the output to 128 bits, resulting in a brute-force collision resistance of only 64 bits.
      Last edited by xnor; 26 May 2021, 04:27 AM.

      Comment


      • #4
        Ok. Let me rephrase: Using non-approved cryptography is considered "not using cryptography" for many sales accounts. The level of cryptanalysis on standard cryptographic algorithms dwarfs the algorithms that the NSA rejected (don't forget, they didn't explain why they rejected BLAKE).

        That Intel CPUs have had broken SHA instructions for ten years is news to me (and probably all those people happily using it to mine bitcoin). Assuming that Intel have since fixed the issue, is it faster than Blake in a fair test?

        Comment


        • #5
          How can you put anything regarding the NSA as a requirement for security when the NSA is known to undermine standards, breaking their security, introducing backdoors?
          BLAKE2 has been subjected to the same types of attacks as any SHA finalist of any SHA competition and other hashing algorithm competitions, for obvious reasons.

          Regarding Intel: the implementation of the instructions is not broken, SHA1 itself is broken. And SHA2 is susceptible to length extension attacks. Those are (unfixable) issues on the level of the algorithm, not the implementation.

          Comment


          • #6
            Originally posted by xnor View Post
            How can you put anything regarding the NSA as a requirement for security when the NSA is known to undermine standards, breaking their security, introducing backdoors?
            BLAKE2 has been subjected to the same types of attacks as any SHA finalist of any SHA competition and other hashing algorithm competitions, for obvious reasons.

            Regarding Intel: the implementation of the instructions is not broken, SHA1 itself is broken. And SHA2 is susceptible to length extension attacks. Those are (unfixable) issues on the level of the algorithm, not the implementation.

            Dunno. Either the NIST is trying to protect the US computer infrastructure, or they are somehow intentionally subverting it and we can't figure out how. Either way they would have to be pretty good at this crypto stuff, and they chose SHA. So people can make up their own mind (and the important people don't wear tinfoil hats).

            I can't see that BLAKE in software is going to be faster than SHA in hardware, so even if the algorithm itself is more efficient it's irrelevant without equivalent silicon in AMD/Intel. Everything else may be the exactly same (as far as the security community currently know).

            Comment


            • #7
              Originally posted by OneTimeShot View Post
              Dunno. Either the NIST is trying to protect the US computer infrastructure, or they are somehow intentionally subverting it and we can't figure out how. Either way they would have to be pretty good at this crypto stuff, and they chose SHA. So people can make up their own mind (and the important people don't wear tinfoil hats).
              NIST, I assume, isn't subverting security but the NSA is. Anyway, the point was that you don't need a tinfoil hat to have concerns when the NSA is mentioned with secure standards in the same sentence since we have evidence.

              Originally posted by OneTimeShot View Post
              I can't see that BLAKE in software is going to be faster than SHA in hardware, so even if the algorithm itself is more efficient it's irrelevant without equivalent silicon in AMD/Intel. Everything else may be the exactly same (as far as the security community currently know).
              But BLAKE using AVX instructions is at the same speed or faster.
              Also, what SHA in hardware? The broken SHA1 that shouldn't be used anymore or SHA256 which is susceptible to length extension attacks, which limits its use or requires more complex constructions (with multiple calls that reduce speed)?

              Comment


              • #8
                OK - talking about the NSA/NIST subverting the security industry may work on an internet forum, but I assume you wouldn't be bringing that up in meetings with your customers. You'll be saying "our product follows FIPS recommendations"

                If and when BLAKE3 is recommended for use because SHA3 is too broken for use, then we can all switch. In the meantime it's an interesting research project.

                for people who have really have a product that needs high speed hashing (that isn't Bitcoin) then yes: cryptographic acceleration hardware is a thing you can pay for. At one point AMD/Intel had support built in to their CPUs. I haven't looked at what state it's in now, of course, but I'd expect that to be the benchmark for real-world performance measurements.

                Comment


                • #9
                  Originally posted by OneTimeShot View Post
                  OK - talking about the NSA/NIST subverting the security industry may work on an internet forum, but I assume you wouldn't be bringing that up in meetings with your customers. You'll be saying "our product follows FIPS recommendations"
                  Or in discussions with anyone who's got a clue.
                  FIPS provides standards and certifies implementations. That doesn't mean you got a secure system. The broken SHA1 is specified in the NIST Secure Hash Standard, and is a NIST-approved algorithm. The updated standards at least say that SHA1 "shall not be used in any new digital signature applications".

                  FIPS also approved DES for the longest time even though it had been known to be insecure. Triple DES is also FIPS-approved, but not something I'd ever use or recommend.

                  Originally posted by OneTimeShot View Post
                  If and when BLAKE3 is recommended for use because SHA3 is too broken for use, then we can all switch. In the meantime it's an interesting research project.
                  Like non-FIPS-approved ChaCha20, that is now used in millions of devices to securely encrypt web traffic without any of the side channel attacks and other attack vectors like on FIPS-approved AES?
                  Also, BLAKE3 is not supposed to be a replacement for SHA3.

                  Originally posted by OneTimeShot View Post
                  for people who have really have a product that needs high speed hashing (that isn't Bitcoin) then yes: cryptographic acceleration hardware is a thing you can pay for. At one point AMD/Intel had support built in to their CPUs. I haven't looked at what state it's in now, of course, but I'd expect that to be the benchmark for real-world performance measurements.
                  You can implement any of the mentioned algorithms in hardware, some for considerably less cost at no loss of security or even higher security.
                  And as for Intel support, didn't you see what I wrote about the Intel SHA instructions?
                  And benchmarks typically use the openssl implementation of SHA1 and SHA256 which make use of these specialized CPU instructions. So the speedup from dedicated instructions is already in the benchmarks. Without those SHA would look worse.
                  Last edited by xnor; 26 May 2021, 07:30 AM.

                  Comment


                  • #10
                    Well, I dunno about the NSA, but BLAKE3 is a ZFS WIP and has good benchmark numbers.

                    Comment

                    Working...
                    X