/dev/random
776128
225753719
2008-07-15T06:41:30Z
Michaeldadmum
1867722
/* See also */
In [[Unix-like]] [[operating system]]s, '''/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 driver]]s and other sources.
Not all operating systems implement the same semantics for '''/dev/random'''.
==Linux==
Linux was the first operating system kernel to implement this kind of operating system-level random number generator.
The implementation uses [[SHA|secure hashes]] rather than [[ciphers]], as required to avoid [[Export of cryptography|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 [[bit]]s of noise in the [[entropy pool]]. From this entropy pool random numbers are created. When read, the <code>/dev/random</code> device will only return random bytes within the estimated number of bits of noise in the entropy pool. <code>/dev/random</code> should be suitable for uses that need very high quality randomness such as [[one-time pad]] or [[public key|key]] generation. When the entropy pool is empty, reads from <code>/dev/random</code> will [[blocking I/O|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 <code>/dev/random</code> is '''/dev/urandom''' ("unlocked" 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 <code>/dev/random</code>. 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 <code>/dev/random</code>. 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. The current amount of entropy and the size of your entropy pool are available in <code>/proc/sys/kernel/random/</code>.
Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator [http://www.pinkas.net/PAPERS/gpr06.pdf] in which they describe several weaknesses. Perhaps the most severe issue they report is with [[embedded system|embedded]] or [[Live CD]] 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 non-volatile 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.
==FreeBSD==
The FreeBSD operating system implements a 256-bit variant of the [[Yarrow algorithm]] to provide a pseudorandom stream - this replaced a previous Linux style random device. Unlike the Linux <code>/dev/random</code>, the FreeBSD <code>/dev/random</code> never blocks. It is similar to the Linux <code>/dev/urandom</code> , intended to serve as a [[cryptographically secure pseudorandom number generator]] rather than based on a pool of entropy (FreeBSD links urandom to random).
Yarrow is based on the assumptions that modern PRNGs are very secure if their internal state is unknown to an attacker, and that they are better understood than the estimation of entropy. Whilst entropy pool based methods are completely secure if implemented correctly, if they overestimate their entropy they may become less secure than well-seeded PRNGs. In some cases an attacker may have a considerable amount of control over the entropy, for example a diskless server may get almost all of it from the network - rendering it potentially vulnerable to man-in-the-middle attacks. Yarrow places a lot of emphasis on avoiding any pool compromise and on recovering from it as quickly as possible. It is regularly reseeded, on a system with small amount of network and disk activity, this is done after fraction of a second.
FreeBSD also provides support for hardware random number generators, which will replace Yarrow when present.
==Other operating systems==
<code>/dev/random</code> and <code>/dev/urandom</code> are also available on [http://blogs.sun.com/yenduri/entry/dev_random_in_solaris Solaris], [http://developer.apple.com/documentation/Darwin/Reference/Manpages/man4/random.4.html Mac OS X], [http://netbsd.gw.com/cgi-bin/man-cgi?rnd++NetBSD-current NetBSD], [http://www.openbsd.org/cgi-bin/man.cgi?query=srandom&apropos=0&sektion=4&manpath=OpenBSD+Current&arch=i386&format=html OpenBSD],
[http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN4/0199____.HTM Tru64 UNIX 5.1B],
[http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.files/doc/aixfiles/random.htm#idx927 AIX 5.2],
and
[http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I HP-UX 11i v2].
In [[Windows NT]], similar functionality is delivered by <code>ksecdd.sys</code>, but reading the special file <code>\Device\KsecDD</code> does not work as in UNIX. The documented methods to generate cryptographically random bytes are
[[CryptGenRandom]] and [[RtlGenRandom]].
==EGD as an alternative==
A software program called '''EGD''' (entropy gathering daemon) is a common alternative for Unix systems which do not support the /dev/random device. It is a [[user space]] [[daemon]] which provides high quality cryptographic random data. Some cryptographic software such as [[OpenSSL]], [[GNU Privacy Guard]], and the [[Apache HTTP Server]] support using EGD when a /dev/random device is not available.
EGD[http://egd.sourceforge.net/], or a compatible alternative such as prngd[http://prngd.sourceforge.net/], gather pseudo-random entropy from various sources, process it to remove bias and improve cryptographic quality, and then make it available over a [[Unix domain socket]] (with '''/dev/egd-pool''' being a common choice), or over a [[Internet_socket|TCP socket]]. The entropy gathering usually entails periodically [[Fork (operating system)|forking]] subprocesses to query attributes of the system that are likely to be frequently changing and unpredictable, such as monitoring CPU, I/O, and network usage as well as the contents of various log files and [[Temporary folder|temporary directories]].
EGD communicates with other programs which need random data using a simple [[Protocol (computing)|protocol]]. The client connects to an EGD socket and sends a command, identified by the value of the first [[octet]]:
* command 0: query the amount of entropy currently available. The EGD daemon returns a 4-byte number in [[Endianness|big endian]] format representing the number of random bytes that can currently be satisfied without delay.
* command 1: get random bytes, no blocking. The second byte in the request tells EGD how many random bytes of output it should return, from 1 to 255. If EGD does not have enough entropy to immediately satisfy the request, fewer bytes, or perhaps no bytes may be returned. The first octet of the reply indicates how many additional bytes, those containing the random data, immediately follow in the reply.
* command 2: get random bytes, blocking. The second byte tells EGD how many random bytes of output it should return. If EGD does not have enough entropy, it will wait until it has gathered enough before responding. Unlike command 1, the reply starts immediately with the random bytes rather than a length octet, as the total length of returned data will not vary from the amount requested.
* command 3: update entropy. This command allows the client to provide additional entropy to be added to EGD's internal pool. The next two bytes, interpreted as a 16-bit big endian integer indicate how many bits of randomness the caller is claiming to be supplying. The fourth byte indicates how many additional bytes of source data follow in the request. The EGD daemon may mix in the received entropy and will return nothing back.
==References==
* [http://msdn2.microsoft.com/en-us/library/aa379942.aspx CryptGenRandom]
* [http://msdn2.microsoft.com/en-us/library/aa387694.aspx RtlGenRandom]
{{reflist}}
==See also==
* [[Unix philosophy]]
* [[Standard streams]]
* <tt>[[:/dev/full]]</tt>
* <tt>[[:/dev/null]]</tt>
* <tt>[[:/dev/zero]]</tt>
* <tt>[[:/dev]]</tt>
* [[Hardware random number generator]]
* [[Cryptographically secure pseudo-random number generator]]
* [[Yarrow algorithm]]
* [[Fortuna (PRNG)| Fortuna algorithm]]
[[Category:Randomness|Dev Random]]
[[Category:Unix|Dev Random]]
[[Category:Device file]]
[[de:/dev/random]]
[[pl:/dev/random]]
[[pt:/dev/random]]
[[ru:/dev/random и /dev/urandom]]
[[tr:/dev/random]]
[[es:/dev/random]]