Linux was the first operating system to expose a kernel-powered CSPRNG to userland, thanks to Theodore Ts’o, who committed added one in Linux 1.3.30, in September 1995. This was done in collaboration with Colin Plumb, who designed the random number generator in the original PGP code base, and Dale Worley. It relied on gathering random signals (interrupts, timers, latencies, inputs, …), and mixing them via MD5.
/dev/urandom to its codebase in March
based on Ts’o work, and it landed in OpenBSD 2.1 in June 1997.
In August 1996, David Mazieres added the
/dev/arnd device, based on
arc4random function was added in December 1996
to OpenBSD 2.1’s libc. It has several advantages over
/dev/urandom: it can’t fail, it’s available in chroots,
is thread-safe, it has better performances since it’s only asking the kernel
for entropy to (re)seed its keystream, … making it easy to use for developers.
arc4random was moved from RC4 to ChaCha20 in October
and so did its kernel counterpart in November 2013;
they both landed in OpenBSD 5.5 in May 2014.
Following OpenBSD’s example, Linux got a new syscall to gather entropy, in July 2014, by Theodore Ts’o, again.
Three years later, in July 2016, he also changed the implementation of the Linux kernel’s implementation to ChaCha20 too, and it landed in Linux 4.8 in October 2016.
Amusingly, in 2017, Amit Klein published an attack to perform DNS poisoning against OpenBSD, exploiting a lack of randomness, and got the following response:
On December 18th, 2007, OpenBSD’s coordinator stated, in an email, that “[OpenBSD is] completely uninterested in the problem” and that “[the] problem […] is completely irrelevant in the real world”. This is in direct contrast to statements and opinions made by the OpenBSD team recently.
The 30th of July 2017, a fun bug was fixed, in Theo de Raadt’s words:
A few optimizations later, a security requirement has been removed.
The issue was that compilers are trying to be clever, (rightly) assuming
const static object will always be zero, even when placed in a
.openbsd.randomdata segment, resulting in useless stack cookies and
Amusingly, the issue has been introduced the 1st of September 2016, and was unnoticed for almost one year!
arc4random in userland is available on various platforms,
even when not being natively implemented, thanks to
FreeBSD, Linux, … have all moved to a
ChaCha20-based CSPRNG. Even Tor is now
using some of its code, for
OpenBSD took inspiration from Linux two decades ago, but nowadays, it’s the other way around, OpenBSD is driving the CSRPNG game!
As for the gory details of OpenBSD’s PRNG, there is a long comment on top of its implementation, but it boils down to being seeded with various timings (keyboard input, interrupts delays, …), all mixed from time to time with a CRC into the entropy pool, which is used (mostly) to (re)seed a ChaCha20 stream cipher, from which entropy is finally presented to the user.
In 2022, Jason A. Donenfeld gave a talk at the Linux Plumbers Conference 2022 about the Linux kernel CSPRNG, and hinted that the OpenBSD one might be problematic: it’s using a non-primitive polynomial for its LFSR.
OpenBSD 7.2, released the 20th of
October 2022 “Randomized the rekey interval of
arc4random(3).”, thanks to a
from djm in July 2022.