Linux Random Number Generator Sees Major Improvements
'An anonymous Slashdot reader summarizes some important news from the web page of Jason Donenfeld (creator of the open-source VPN protocol WireGuard): The Linux kernel's random number generator has seen its first set of major improvements in over a decade, improving everything from the cryptography to the interface used. Not only does it finally retire SHA-1 in favor of BLAKE2s [in Linux kernel 5.17], but it also at long last unites '/dev/random' and '/dev/urandom' [in the upcoming Linux kernel 5.18], finally ending years of Slashdot banter and debate: The most significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing, with no differences between them at all, thanks to their unification in random: block in /dev/urandom. This removes a significant age-old crypto footgun, already accomplished by other operating systems eons ago. [...] The upshot is that every Internet message board disagreement on /dev/random versus /dev/urandom has now been resolved by making everybody simultaneously right! Now, for the first time, these are both the right choice to make, in addition to getrandom(0); they all return the same bytes with the same semantics. There are only right choices. Phoronix adds: One exciting change to also note is the getrandom() system call may be a hell of a lot faster with the new kernel. The getrandom() call for obtaining random bytes is yielding much faster performance with the latest code in development. Intel's kernel test robot is seeing an 8450% improvement with the stress-ng getrandom() benchmark. Yes, an 8450% improvement.' -- source: https://linux.slashdot.org/story/22/03/19/1821254 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 (office) +64 (7) 577-5304 (home office) https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/
On Mon, 21 Mar 2022 10:42:07 +1300, Peter Reutemann quoted:
'The most significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing, with no differences between them at all, thanks to their unification in random: block in /dev/urandom.'
Just to be clear what is happening here, the original distinction between reading random bytes from /dev/random versus /dev/urandom was that the former always guarantees to have some genuine entropy (physical randomness) to give you, whereas the latter would fake it by falling back to a pseudorandom sequence if it ran out of entropy. So long as there was enough randomness for the starting point, /dev/urandom would produce a stream of bytes that was good enough for most security-related purposes. But for the most security-critical uses (e.g. generation of long-term keys), those who are paranoid might still have preferred to use /dev/random, however long it takes to return a result. A problem could occur on this score during the early stages of booting, before the system had collected enough randomness to seed the random number generator, which could cause hangs on code trying to use /dev/random. This issue seems to be mostly resolved now. What the new kernel changes have done is guarantee that your system will have enough randomness within about one second of booting so that it becomes feasible to use /dev/random as your source of randomness for everything. And /dev/urandom now becomes just another name for this.
On Mon, Mar 21, 2022 at 11:50:04AM +1300, Lawrence D'Oliveiro wrote:
What the new kernel changes have done is guarantee that your system will have enough randomness within about one second of booting so that it becomes feasible to use /dev/random as your source of randomness for everything. And /dev/urandom now becomes just another name for this.
What I would be interested in knowing, is how do they actually achieve the sufficient randomness within one second. What is the trick to achieve this? Cheers, Michael.
On Mon, 21 Mar 2022 14:55:33 +1300, Michael Cree wrote:
What I would be interested in knowing, is how do they actually achieve the sufficient randomness within one second. What is the trick to achieve this?
Apparently three years ago Linus Torvalds added a quick patch which sampled CPU clock jitter. He wasn’t entirely convinced it was effective, but it seems to have held up so far.
On Mon, 21 Mar 2022 10:42:07 +1300, Peter Reutemann quoted:
'The most significant outward-facing change is that /dev/random and /dev/urandom are now exactly the same thing'
This report <https://www.theregister.com/2022/03/21/new_linux_kernel_has_improved/> adds one little fact I didn’t know: that the idea for a /dev/random device originated on Linux, and was rapidly copied by just about all the major Unixes: The code is contained in a module called random.c, originally written by Ted T'so for kernel 1.3 in 1994. It implements a Unix-style special character device called /dev/random which gives a stream of pseudorandom data. Building this into the kernel was a big deal, and the /dev/random device was adopted into DEC/Compaq Tru64, FreeBSD, HP-UX, IBM AIX, NetBSD, macOS, SGI IRIX, and Sun Solaris. This might make it one of the single most widely influential new features from Linux onto the broader Unix world.
participants (3)
-
Lawrence D'Oliveiro -
Michael Cree -
Peter Reutemann