The venerable Linux /dev/random served users of cryptographic mechanisms well for a long time. Its behavior is well understood to deliver entropic data. In the last years, however, the Linux /dev/random showed signs of age where it has challenges to cope with modern computing environments ranging from tiny embedded systems, over new hardware resources such as SSDs, up to massive parallel systems as well as virtualized environments. This paper proposes a new approach to entropy collection in the Linux kernel with the intention of addressing all identified shortcomings of the legacy /dev/random implementation. The new Linux Random Number Generator's design is presented and all its cryptographic aspects are backed with qualitative assessment and complete quantitative testing. The test approaches are explained and the test code is made available to allow researchers to re-perform these tests.
The Linux Random Number Generator is an API and ABI compatible drop-in replacement to the legacy /dev/random implementation in the Linux kernel.
A PDF documentation is also available. The pictures and graphs are better to read in the PDF version.
The following source code contains the implementation of the Linux Random Number Generator.
Removal of the Jitter RNG fast noise source as requested by Ted
Addition of processing of add_input_randomness as suggested by Ted
Update documentation and testing to cover the updates
Addition of a SystemTap script to test add_input_randomness
To clarify the question whether sufficient entropy is present during boot I added one more test in 3.3.1 which demonstrates the providing of sufficient entropy during initialization. In the worst case of no fast noise sources, in the worst case of a virtual machine with only very few hardware devices, the testing shows that the secondary DRBG is fully seeded with 256 bits of entropy before user space injects the random data obtained during shutdown of the previous boot (i.e. the requirement phrased by the legacy /dev/random implementation). As the writing of the random data into /dev/random by user space will happen before any cryptographic service is initialized in user space, this test demonstrates that sufficient entropy is already present in the LRNG at the time user space requires it for seeding cryptographic daemons. Note, this test result was obtained for different architectures, such as x86 64 bit, x86 32 bit, ARM 32 bit and MIPS 32 bit.
Convert debug printk to pr_debug as suggested by Joe Perches
Add missing \n as suggested by Joe Perches
Do not mix in struck IRQ measurements as requested by Pavel Machek
Add handling logic for systems without high-res timer as suggested by Pavel Machek -- it uses ideas from the add_interrupt_randomness of the legacy /dev/random implementation
add per NUMA node secondary DRBGs as suggested by Andi Kleen -- the explanation of how the logic works is given in section 2.1.1 of my documentation , especially how the initial seeding is performed.
port to 4.7-rc1
Use classical twisted LFSR approach to collect entropic data as requested by George Spelvin. The LFSR is based on a primitive and irreducible polynomial whose taps are not too close to the location the current byte is mixed in. Primitive polynomials for other entropy pool sizes are offered in the code.
The reading of the entropy pool is performed with a hash. The hash can be specified at compile time. The pre-defined hashes are the same as used for the DRBG type (e.g. a SHA256 Hash DRBG implies the use of SHA-256, an AES256 CTR DRBG implies the use of CMAC-AES).
Addition of the example defines for a CTR DRBG with AES128 which can be enabled during compile time.
Entropy estimate: one bit of entropy per interrupt. In case a system does not have a high-resolution timer, apply 1/10th bit of entropy per interrupt. The interrupt estimates can be changed arbitrarily at compile time.
Use kmalloc_node for the per-NUMA node secondary DRBGs.
Add boot time entropy tests discussed in section 3.4.3 .
Align all buffers that are processed by the kernel crypto API to an 8 byte boundary. This boundary covers all currently existing cipher implementations.
fix treating LRNG_POOL_SIZE_BITS as entropy value in lrng_get_pool
use CTR DRBG with AES256 as default due to its superior speed -- on X86_64 executing within a KVM I get read speeds of up to 850 MB/s now. When using a fake NUMA system with 4 nodes on 4 CPUs, I still get up to 430 MB/s read speed with four parallel reads. Note, this patch applies to the current cryptodev-2.6 tree.
use DRBG security strengths as defined in SP800-57 section 5.6.1
add security strength to /proc/sys/kernel/random/lrng_type
add ChaCha20 DRNG: in case the kernel crypto API is not compiled, the ChaCha20 DRNG with the SHA-1 C implementations are used to drive the cryptographic part of the LRNG.The ChaCha20 RNG is described in . I analyzed it with a user space version of it.
Editorial changes requested by checkpatch.pl
port to 4.8-rc1
add missing memzero_explicit to ChaCha20 DRNG
use kernel-doc documentation style
use of min3 in lrng_get_pool to beautify code
prevent fast noise sources from dominating slow noise sources in case of /dev/random
set read wakeup threshold to 64 bits to comply with legacy /dev/random
simplify the interrupt to entropy amount conversion code
move wakeup call of entropy-providers to a code location where /dev/urandom will benefit from the wake up as well (i.e. when the primary DRBG entropy runs low because of /dev/urandom reseeds, the entropy provider is woken up)
inject current time into primary DRBG at the time of seeding from noise sources (suggested by Sandy Harris)
port to 4.9-rc1
add lrng_drng_generate_helper_full() function for DRNGs to inform them about requests that shall have the capability to transport close to 1 bit of entropy per data bit
streamline code in lrng_pdrbg_seed_internal
test NUMA code on real NUMA system: fixes of NUMA support code to support deactivated NUMA nodes
constify buffers to crypto operations
port to kernel v4.10-rc1
fix race condition in add_interrupt_randomness when low res timer is used
re-add Jitter RNG noise source assumed to provide one 16th bit of entropy per data bit (every source of entropy is helpful)
make LFSR invocation much more efficient in hot code paths
increase reseed threshold of secondary DRBG to 2^17 requests (maximum number of bytes to be generated without reseeding attempt: 2^17 requests * 2^12 bytes per requests)
initialize ChaCha20 key space with time stamp and arch_get_random_long
reseed the secondary DRBG always with full entropy equal to its security strength -- further details are given in section 2.6 of the documentation
add FIPS 140-2 continuous self test to ChaCha20 code path