Future-Proofing: Proactively moving to newer algorithms can help us stay ahead of potential (even if distant) weaknesses in SHA-2. Things like Grover’s algorithm in a quantum future, for example, theoretically reduce the effective strength of all hashes, making more modern designs potentially more resilient in the long run. SHA-2 was 2001
Better Alternatives Exist:
SHA-3 (Keccak): It’s a NIST standard with a completely different internal structure than SHA-2, which is great for security diversity (if one breaks, the other is likely fine). It also inherently resists things like length extension attacks. 2015
BLAKE3: This is a newer algorithm known for being incredibly fast, often much faster than SHA-2 and SHA-3, especially on modern multi-core processors. It also has strong security, building on the well-regarded BLAKE2. 2020
Potential Benefits:
Stronger security posture.
With BLAKE3, potentially noticeable performance improvements in areas like package handling, build systems, and file integrity checks.
What would be involved?
Obviously, this isn’t a trivial change. It would mean:
Checking compatibility across the ecosystem.
A likely phased rollout.
Community effort for testing and implementation.
The Question:
Is this something the Fedora community thinks is worth exploring more? Should we start looking into the pros and cons of moving to something like SHA-3 or BLAKE3 as the default for new package signing, checksums, etc., in a future Fedora release?
Would love to hear your thoughts and if there’s interest in forming a small group to investigate this further.
Both are currently considered secure. SHA-3 uses a different internal algorithm. I didnt like to see the NIST trying in 2013 to alter the original submission parameters, but the NIST, after being publically spanked hard by both Bruce Schneier and Daniel Bernstein, the final spec went back to the original paramters and higher level of security.
SHA-2 has more hardware support and in some contexts if it required by law (in the USA but not only) for some cryptographic uses when you want to sell software and/or hardware to anything that will be used inside governments. So.. even if we start using SHA-3 we will have to keep SHA-2 for… some time (until those laws and regulations get updated).
SHA-3 does have a higher security margin, but this comes at the price of being sensibly slower than SHA-2…
Are you thinking of a particular attacks against SHA-2 reduced-rounds that have been published during the SHA-3 development ?
The SHA1 deprecation is barely finished, and given OP mentions there is less support for SHA3 or BLAKE3 yet (mostly SHA2 and blake2b) is it really the time to do yet another switch?
I haven’t been into the debate of crypto for some time, but I doubt that BLAKE3 has yet the review (a core element in crypto security) of its alternatives (mabye someone knows more?). So I would not consider it unless there is a weakness identified if one of the others that forces us to change. BLAKE2 is a great thing for software, and well reviewed, and with technologies like Wireguard it got even more review: not sure if we already need to consider a replacement? It speed is absolutely fine, great software performance, and the review makes its security “predictable”.
SHA3 is fine on hardware, but there is yet nearly no hardware, and it is weak on software. It was intended as alternative for SHA2 when everyone was shocked of the identification of “length extension attacks”, affecting all Merkle-Damgard-constructions (both sha1 and sha2).Primary goal: it has to be as different as possible to SHA2 → in case one of the two gets broken, the other should be the alternative. Obviously, after the revelation of length extension attacks, there was fear that there are further issues we haven’t had identified at the time, which would have left us with no alternatives at the time. However, this has proven to not apply, SHA2 is now likely the best reviewed hash algorithm there is, and length extension attacks are well understood and easy to mitigate (which of course leaves the risk of human error of misuse it - but that’s obviously a different topic). That might be also linked to the reason that SHA3 remains a niche product, not in widespread use.
In short, there is no reason to consider SHA3 more secure than SHA2, especially if its massive review is considered. And in many use cases (I tend to argue: MOST usecases), it will be in practice much slower than SHA2.
Keep also in mind that SHA2 is increasingly implemented in hardware, which boosts its performance on many systems (number increasing). That also adds security possibilities compared to software implementations.
However, it would be indeed interesting to know how BLAKE3 compares to BLAKE2 alternatives in real world use cases Do we have benchmarks of software implementations or so? (just out of curiosity:)
I forgot: these hashes should have the same resilience in this respect
Good points. SHA-3 offers long-term resilience but is slower which is true due to sponge construction and lacks hardware support. BLAKE3 is fast but newer and and getting standardized .
As you have mentioned SHA2 is often legally required. Though i really don’t know about the legality part ofcourse.
If you ask yes SHA2 is more prone to be affected by Grovers algorithm and my point is better be have more security and it is not all about security though there will be a huge performance gain due to the fact that newers systems have Avx12 10 or 512 which can reduce calculation time in half and blake3 provide a huge benifit for muti core CPUs which everyone have.
For the performance part
3–10x faster than SHA-2 in benchmarks, thanks to SIMD and multithreading as per benchmark only.
Near-integrity checks for large files (ISOs, containers).
Could be many other that i could not able to mension right now.
And yes, Blake3 and SHA3 will be more resilient against quantum systems and grovers algo.
But yes SHA3 have performance penalty but blake3 does not have.
Maybe a “transition” will be more appropriate word to choose here.
As technology moves. And compute power increase exponentially we need to move with that graph.
This is not just for security it have multiple other benifits from performance to security and ultimately SHA2 is a 2001 tech and it is 2025 we are transitioning towards AI and QUANTUM COMPUTERS.
As always you made a nice point.
What i know blake3 builds on BLAKE2, which has undergone extensive review from wireguard and linux you have mentioned.
In the case of SHA 2
its Merkle-Damgård construction is older and lacks modern features (parallelism, KDF, XOF etc.).
Now Why?
Even without SHA-2 being “broken,” BLAKE3 offers practical advantages (performance, flexibility , security) with enhanced security. For me this is a big deal.
Benchmarks:
Why Not Just Stick with BLAKE2?
BLAKE2 is excellent—but BLAKE3 improves on it with:
Standardized extendable output (like SHAKE, useful for derived keys).
Better parallelism (scales with core count, unlike BLAKE2s/2b).
I only read the wiki stuff you mentioned, but it mentions differences that make me doubt that security guarantees of blake2 can be transferred to blake3.
The increasing existence of SHA2 implementation in hardware partly resolves the first issue and adds several advantages compared to any blake, and I am not sure if we have a need for the other two you mentioned in the way offered here, at least not in a way that justifies the change with all its disadvantages. I was once playing with XOF, funny thing to use a hash as stream cipher, but for that we have today ChaCha20, and I am not sure if there are use cases at the moment that would justify the change considering the disadvantages (less review, less compatibility, less implementations, working time that might be better used elsewhere, …). For KDF, we have established, widespread and well understood means too.
It is indeed possible that Blake3 will replace Blake2 in some time, but that time has not yet come. Blake2 does its job well, is well understood (including its implementations) and is a de-facto standard for several areas. Things like this take time, crypto is a sensitive matter: it is not just the security of the algorithm, but also of its implementations. People have to get used to it, code needs review and testing too. Coders need to get the differences and considerations, and that needs review too. And so on.
As for SHA3, I think it remains a niche product, as the fears for which it was developed have not come true, and its weaknesses in software are a game breaker in many respects.
However, I always appreciate if people worry about their crypto, its a matter too often neglected. I remember the times in which online banking cyber security awards have been given to institutions that use RC4 crypto in times post-AES
Do we have benchmarks of software implementations or so? (just out of curiosity:)