/dev/random implementation proposed for the Linux kernel, freed from binding to SHA-1

Jason A. Donenfeld, the author of VPN WireGuard, has proposed an updated implementation of the RDRAND pseudo-random number generator responsible for /dev/random and /dev/urandom devices in the Linux kernel. At the end of November, Jason was included in the number of maintainers of the random driver and has now published the first results of his work on its revision.

The new implementation is notable for the switch to using the BLAKE2s hash function instead of SHA1 for entropy mixing operations. The change made it possible to increase the security of the pseudo-random number generator by getting rid of the problematic SHA1 algorithm and eliminating the overwriting of 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 (testing on a system with an Intel i7-11850H processor showed a 131% increase in speed). Another advantage of transferring entropy mixing to BLAKE2 was the unification of the algorithms used - BLAKE2 is used in the ChaCha cipher, which is already used to extract random sequences.

In addition, improvements have been made to the cryptographically secure CRNG pseudo-random number generator used in the getrandom call. The improvements come down to limiting the call to the slow RDRAND generator when extracting entropy, which improves performance by 3.7 times. Jason showed that calling RDRAND only makes sense when the CRNG has not yet been fully initialized, but if the initialization of the CRNG is complete, its value does not affect the quality of the generated sequence, and RDRAND can be dispensed with in this case.

The changes are scheduled for inclusion in the 5.17 kernel and have already been reviewed by developers Ted Ts'o (second random driver maintainer), Greg Kroah-Hartman (responsible for maintaining the stable branch of the Linux kernel) and Jean-Philippe Aumasson (author of BLAKE2/3 algorithms).

Source: opennet.ru

Add a comment