The commit message criticizes SHA1 pretty well but why did they specifically choose Blake2? Donenfeld is clearly very smart but did they have a bake off?
When choosing a cryptographic algorithm, there are generally two schools of thought:
• Use something FIPS approved and tried and true (RSA, SHA-256, AES in GCM, maybe a NIST/FIPS curve, although Google “Dual_EC_DRBG” first, etc.)
• Use a cryptographic primitive developed by Daniel J. Bernstein (Curve25519—which, yes, is NIST if maybe not FIPS approved, [1] ChaCha20 and its derivative BLAKE2, etc.)
These are two camps, and there is some tension between the two camps (as can be seen elsewhere in this discussion) about which approach is better, with very heated emotions. While heated, as someone who remembers the BIND-vs-djbdns and Sendmail-vs-Qmail flame wars of 20 years ago all too well, [2] I find an old fashioned to-DJB-or-not-to-DJB heated discussion a refreshing blast from the past compared to the kind of toxic cancel culture, doxxing, and hideous political attacks dominating social media here in the 2020s.
For a brand new project using crypto, I would use libsodium, which is firmly in the DJB school of thought w.r.t. cryptographic algorithms used, simply because, while newer, it doesn’t have the security history OpenSSL has had, and looks to be quite secure and actively maintained by multiple developers.
[2] I used Qmail and djbdns during that era before transitioning to my own MaraDNS. I only made MaraDNS because of the concerns about djbdns’ then-not-open-source license and the lack of open source diversity w.r.t. DNS servers back then. All moot, now that Qmail/djbdns are public domain, both NSD/Unbound and KnotDNS have come out, and Postfix has become the most common non-Sendmail email daemon. Actually, w.r.t. email, I use an online service here in the 2020s (mxroute), because the headaches of bypassing spam filters are now such it’s best left to someone devoted to just that one problem.
[3] My preferences tend to win the NIST standardization workshops. I liked Rijndael the most during the AES process because it, unlike the others, has a variable block size, so can be used for stuff like AEShash-256. I liked Keccak the most during the SHA-3 process because it was the only unbroken extensible output function (XOF) which ran decently on 32-bit hardware; the only other unbroken XOF, Skein, was pretty much 64-bit only, and BLAKE didn’t have an XOF mode at the time. I still wish BLAKE had a sponge-style “rehash to generate more random bits” XOF mode to make fast forwarding its XOF computationally infeasible.
Blake is one of the faster SHA3 finalists out there and the ‘s’ variety is fast on 32-bit hardware. I don’t know why they chose Blake2 instead of Blake3, though.
Not to nitpick but BLAKE was the SHA3 finalist, not BLAKE2 which is an improvement.
To quote Wikipedia:
>BLAKE2 removes addition of constants to message words from BLAKE round function, changes two rotation constants, simplifies padding, adds parameter block that is XOR'ed with initialization vectors, and reduces the number of rounds from 16 to 12 for BLAKE2b (successor of BLAKE-512), and from 14 to 10 for BLAKE2s (successor of BLAKE-256).
Reducing the rounds by 4 might raise eyebrows wrt security, but Aumasson's 'Too Much Crypto' discusses BLAKE vs BLAKE2 among other things: https://eprint.iacr.org/2019/1492.pdf
Why kernel devs didn't go with BLAKE3, I can't say.
Your doubly linked comment (adrian_b’s remark) makes the incorrect assertion that the only reason blake3 is faster than blake2 is parallelism; this is objectively false. Blake3 uses fewer rounds (7x2) of the Chacha primitive than blake2 (10x2).
I think tptacek has it right: this thing is used very infrequently (period 300 seconds) and blake2 was already in the kernel, so they just reused it. It’s adequately fast, even if blake3 would be marginally faster.
I do not think that he claimed that the reason is performance, but regardless, I gave other reasons besides performance, too, including "blake2 was already in the kernel, so they just reused it". I said: "BLAKE2 is already in the kernel (with tests and everything), while BLAKE3 is not (at all)".
I'm not familiar with the kernel RNG specifically, but I think the hash function is only used with small inputs and outputs, and it's the stream cipher (ChaCha) that has the more performance-sensitive job of generating lots of output bytes. So the performance differences between BLAKE2s and BLAKE3 probably aren't very important here, and the fact that a BLAKE2s implementation is already in the kernel makes this an easy change.
That makes sense, thanks. I wonder if it might make sense to use a reduced-round Chacha for generation. Aumasson calls for 8 rounds; I think Rust’s CSPRNG uses 12.
To sum up: BLAKE3 has no advantages over BLAKE2 when it comes to the Linux kernel[1], plus BLAKE2 is already in the kernel (with tests and everything), while BLAKE3 is not (at all). That, and BLAKE3 is still fairly new.
[1] It is faster than BLAKE2 due to parallelism, which is not suitable for the Linux kernel; you want to restrict computation to a single thread instead of making all the cores busy. FWIW, the C reference implementation is not multi-threaded either.
https://lwn.net/Articles/879391/