/dev/random
From Wikipedia, the free encyclopedia
In Unix-like operating systems, /dev/random is a special file that serves as a true random number generator or as a pseudorandom number generator. It allows access to environmental noise collected from device drivers and other sources. Not all operating systems implement the same semantics for /dev/random.
[edit] Linux
Linux was the first operating system to implement this kind of operating system level random number generator. The implementation uses secure hashes rather than ciphers, as required to avoid legal restrictions that were in place when the generator was originally designed. The implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses. Fast recovery from pool compromise is not considered a requirement, because the requirements for pool compromise are sufficient for much easier and more direct attacks on unrelated parts of the operating system.
In this implementation the generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. (Source: Linux Programmer's Manual, section 4)
The intent is to serve as a true random number generator, delivering real entropy for the most random data possible. This is suggested for use in generating cryptographic keys for high-value or long-term protection.
A counterpart to /dev/random is /dev/urandom ("unlimited" random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. The intent is to serve as a cryptographically secure pseudorandom number generator. This may be used for less secure applications.
It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate.
Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator [1] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or LiveCD systems such as routers and diskless clients, for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with flash memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.
[edit] FreeBSD
The FreeBSD operating system implements the Yarrow algorithm to provide a pseudorandom stream. Unlike the Linux /dev/random, the FreeBSD /dev/random never blocks. It is the functional equivalent of the Linux /dev/urandom, intended to serve as a cryptographically secure pseudorandom number generator rather than as a true random number generator delivering entropy.
Yarrow was designed to recover quickly from pool compromise. This is of very limited value, because the access requirements needed to compromise the pool are sufficient to perform far easier attacks on unrelated parts of the operating system. Compared to the Linux algorithm, Yarrow uses a very small pool. Yarrow relies on the security of modern ciphers, unlike the Linux algorithm which is designed to remain secure even if the underlying cryptographic functions are eventually found to be weak.
