Jason A Donenfeld, author of VPN WireGuard made it known a few days ago a new implementation updated from a random number generator RDRAND, which is responsible for the /dev/random and /dev/urandom devices in the Linux kernel.
At the end of November, Jason was listed as a random controller maintainer and has now posted the first results of his rework work.
It is mentioned in the announcement that the new implementation is notable for the switch to using the BLAKE2s hash function instead of SHA1 for entropy mixing operations.
BLAKE2s itself has the nice property of being based internally on the
ChaCha permutation, which the RNG is already using for the expansion, so
there should be no problem with novelty, originality or amazing CPU
behavior, since it is based on something that is already in use.
In addition, it is noted that the change also improved the security of the pseudorandom number generator by getting rid of the troublesome SHA1 algorithm and avoiding overwriting the RNG initialization vector. Since the BLAKE2s algorithm is ahead of SHA1 in performance, its use also had a positive effect on the performance of the pseudo-random number generator (tests on a system with an Intel i7-11850H processor showed a 131% increase in speed). ).
Another advantage that stands out is that of transferring the entropy mixture to BLAKE2 is the unification of the algorithms used: BLAKE2 is used in the ChaCha cipher, which is already used to extract random sequences.
BLAKE2s is generally faster and certainly more secure, It has been really very broken. Besides, the current build in the RNG does not use the full SHA1 function, as specifies, and allows to overwrite the IV with the RDRAND output so undocumented, even if RDRAND is not configured as "trusted", which which means possible malicious IV options.
And its short length means to keep only half a secret when feeding back to the mixer it gives us only 2^80 bits of forward secrecy. In other words, not only the choice of the hash function is outdated, but its use is also not really good.
Also, improvements have been made to the crypto-safe CRNG pseudo-random number generator used in the getrandom call.
It is also mentioned that improvements boil down to limiting the call to the RDRAND generator slow when extracting entropy, which can improve performance by a factor of 3,7. Jason demonstrated that the call to RDRAND It only makes sense in a situation where the CRNG has not been fully initialized yet, but if the CRNG initialization is complete, its value does not affect the quality of the generated stream, and in this case, it is possible to do so without calling RDRAND.
This compromise aims to solve these two problems and, at the same time, maintain the general structure and semantics as close as possible to the original.
Specifically:a) Instead of overwriting the IV hash with RDRAND, we put in the documented BLAKE2 "salt" and "personal" fields, which are created specifically for this type of use.
b) Since this function returns the result of the complete hash to the entropy collector, we only return half the length of the hash, just like it was done before. This increases the build advance secret from 2^80 to 2^128 much more comfortable.
c) Instead of just using the raw "sha1_transform" function, instead we use the full and proper BLAKE2s function, with completion.
Changes are scheduled for inclusion in kernel 5.17 and have already been reviewed by developers Ted Ts'o (the random driver's second maintainer), Greg Kroah-Hartman (responsible for keeping the Linux kernel stable), and Jean-Philippe Aumasson (author of the BLAKE2 algorithms /3).
Finally, if you are interested in being able to know more about it, you can consult the details in the following link