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.
For Linux 5.17 there are some nice "random" improvements. Jason Donenfeld who is best known for his work on creating WireGuard is also the Linux kernel's random maintainer. Queued today was the change to remove SHA1 usage from the random.c code and to instead use BLAKE2s.
Donenfeld noted in the patch, "BLAKE2s is generally faster, and certainly more secure, than SHA1, which has been really very broken. Additionally, the current construction in the RNG doesn't use the full SHA1 function, as specified, and allows overwriting the IV with RDRAND output in an undocumented way, even in the case when RDRAND isn't set to "trusted", which means potential malicious IV choices. And its short length means that keeping only half of it secret when feeding back into the mixer gives us only 2^80 bits of forward secrecy. In other words, not only is the choice of hash function dated, but the use of it isn't really great either."
Switching to using BLAKE2s will make things more secure and faster. Initial seeding on an Intel laptop was found to be about 131% faster with this change.
Random.git also saw other fixes queued today ahead of these changes that will debut in the upcoming Linux 5.17 merge window.
For Linux 5.17 there are some nice "random" improvements. Jason Donenfeld who is best known for his work on creating WireGuard is also the Linux kernel's random maintainer. Queued today was the change to remove SHA1 usage from the random.c code and to instead use BLAKE2s.
Donenfeld noted in the patch, "BLAKE2s is generally faster, and certainly more secure, than SHA1, which has been really very broken. Additionally, the current construction in the RNG doesn't use the full SHA1 function, as specified, and allows overwriting the IV with RDRAND output in an undocumented way, even in the case when RDRAND isn't set to "trusted", which means potential malicious IV choices. And its short length means that keeping only half of it secret when feeding back into the mixer gives us only 2^80 bits of forward secrecy. In other words, not only is the choice of hash function dated, but the use of it isn't really great either."
Switching to using BLAKE2s will make things more secure and faster. Initial seeding on an Intel laptop was found to be about 131% faster with this change.
Random.git also saw other fixes queued today ahead of these changes that will debut in the upcoming Linux 5.17 merge window.
8 Comments