Historically, the kernel's RNG was fairly slow and did not take advantage of as many entropy sources as it could have. Historical documentation that expected larger values in this file, or expected the user to take actions if the value was getting "too low", can be disregarded.Īpplications that do not need cryptographically secure random numbers can simply use a non-cryptographic random number generator, for example random(3).įor applications that do need cryptographically secure random numbers, there generally is no need for anything other than the kernel's RNG. Therefore, /proc/sys/kernel/random/entropy_avail should always contain 256, which is the size of a ChaCha20 key in bits. Note that because /dev/random no longer aims to provide true random data, but rather "just" cryptographically secure random data (which is sufficient for all real-world use cases), reading from it no longer causes the kernel's entropy pool to deplete. Therefore, in the general case, users and applications should still follow the traditional guidance of using /dev/random when generating long-term cryptographic keys, or use getrandom(2) which by default behaves similarly to /dev/random. On other architectures (specifically, architectures that do not have a fast cycle counter), there is one remaining difference between the two: /dev/random blocks until the kernel has estimated that the CRNGs are properly initialized, whereas /dev/urandom does not. (This is true because the presence of the RDTSC instruction on all x86-64 CPUs means that the CPU-based jitterentropy algorithm will always be able to generate entropy, not to mention that most x86-64 CPUs also support RDRAND.) Since Arch Linux only supports x86-64, /dev/random and /dev/urandom are equivalent on Arch Linux. However, the behavior of /dev/random and /dev/urandom has significantly converged over time, and on x86-64 systems they are now equivalent. Historically, /dev/random was considered to provide stronger random numbers than /dev/urandom. The Linux RNG provides three interfaces for userspace to get random data: Entropy continues to be collected, and the CRNGs are periodically reseeded, as long as the kernel is running. The entropy is extracted using the BLAKE2s cryptographic hash function and used to seed a set of ChaCha20 CRNGs (Cryptographic Random Number Generators) that provide the actual random data. No single entropy source is relied on exclusively. It works by collecting entropy from various sources, such as hardware RNGs, interrupts, and CPU-based jitterentropy. The Linux kernel's built-in RNG produces cryptographically secure pseudorandom data. This page describes the current implementation and behavior, applicable to modern kernels including Arch Linux's officially supported kernels.
As such, much information that exists about it is outdated. Note: the Linux RNG has been improved significantly in recent years, with many changes occurring in the 4.x and 5.x kernel series.
0 kommentar(er)
