Linux 5.17 To Replace SHA1 With BLAKE2s For Faster & More Secure "Random"

[phoronix]

Phoronix: Linux 5.17 To Replace SHA1 With BLAKE2s For Faster & More Secure "Random"

Queued today within the Linux's random.git repository for the /dev/random and /dev/urandom code is support for using BLAKE2s rather than SHA1 when hashing the entropy pool. This in turn is a big performance speed-up in addition to being more secure...

https://www.phoronix.com/scan.php?pa...Random-BLAKE2s

[OmniNegro]

SHA1 has been broken for around fifteen years now. Even Windows was supposedly going to replace it with SHA256. But I do not think they ever did. Linux has finally been the first to fix this steaming pile of "expletives deleted".

Bravo!

[curfew]

SHA1 has been broken for around fifteen years now. Even Windows was supposedly going to replace it with SHA256. But I do not think they ever did. Linux has finally been the first to fix this steaming pile of "expletives deleted".

Being broken for one use case thing doesn't necessarily make it broken for all use cases.

[Danny3]

What about the ability of not trusting the CPU's hardware random number generator with a kernel parameter, will it still work, would there be any performance improvements for that case ?

[markg85]

While BLAKE2 is definitely fast and just better then SHA, it has already been superseded by BLAKE3 which is vastly superior in terms of speed to anything before it.
It even looks like IPFS could be going the BLAKE2 or 3 route when they revise their CID hashing.

To be complete, i do get it if projects don't want to adopt BLAKE3 just yet because it's still relatively new. Tech like this probably needs a few years to set in, have some researchers looked at it from a security point of view before it gets acceptable to use widely.

[Jakobson]

While BLAKE2 is definitely fast and just better then SHA, it has already been superseded by BLAKE3 which is vastly superior in terms of speed to anything before it.
It even looks like IPFS could be going the BLAKE2 or 3 route when they revise their CID hashing.

To be complete, i do get it if projects don't want to adopt BLAKE3 just yet because it's still relatively new. Tech like this probably needs a few years to set in, have some researchers looked at it from a security point of view before it gets acceptable to use widely.

The fastness of a random hash function of kernel LRNG is indifferent. The quality of entropy sources and mixing them is much much more important. Kernel PRNG (/dev/urandom) is fast enough for everyone. If it still would not be fast enough then why to spend enormous time on continuous context switchings when you can utilize PRNG totally in userland and only occasionally seed it from kernel space?

[numacross]

SHA1 has been broken for around fifteen years now. Even Windows was supposedly going to replace it with SHA256. But I do not think they ever did.

They have. At first they signed updates with both SHA-1 and SHA-2, but since 2019 it's SHA-2 only. Other uses of code signing are more complicated, I don't think they outright invalidated all SHA-1 based ones - that would break too much, but for critical pieces (updates and drivers) it's SHA-2 only.

[willmore]

Does BLAKE2 or BLAKE3 take advantage of any of the CPU acceleration instructions for the SHA family of cyphers? Or did the kernel not take advantage of these instructions?

[rincebrain]

Does BLAKE2 or BLAKE3 take advantage of any of the CPU acceleration instructions for the SHA family of cyphers? Or did the kernel not take advantage of these instructions?

AFAIK the Intel SHA-NI instructions are very, very specific to SHA1/SHA256 - they're basically "calculate this specific part of (SHA1|SHA256)", and not more generally useful.

That said, BLAKE2 (and variants)/BLAKE3 aren't the fastest hash in the west without using the handrolled SIMD accelerated implementations, and BLAKE3 in particular is much faster than variants of BLAKE2...on x86, where they've nicely made accelerated versions using SSE2/SSE41/AVX2/AVX512 which go markedly faster the further on the list you go. On platforms that aren't x86, where they haven't necessarily written lovingly optimized SIMD-ful ASM, the differential between BLAKE3 and others (including BLAKE2b, for example) can look very different.

(And of course, SHA256 still kicks BLAKE3's ass on platforms where you get SHA-NI or equivalent like ARM's sha2 extension, because the perf of using those extensions is so remarkably different...I never really thought I'd be thinking of SHA256 as the fast option on newer platforms, but the world is a strange place.)