RANDOM(4) BSD/i386 Kernel Interfaces Manual RANDOM(4)NAME
random, urandom — random number devices
DESCRIPTION
This device gathers environmental noise from device drivers, etc., and
returns good random numbers, suitable for cryptographic use. Besides the
obvious cryptographic uses, these numbers are also good for seeding TCP
sequence numbers, and other places where it is desirable to have numbers
which are not only random, but hard to predict by an attacker.
Theory of operation
Computers are very predictable devices. Hence it is extremely hard to
produce truly random numbers on a computer — as opposed to pseudo-random
numbers, which can easily be generated by using an algorithm. Unfortu‐
nately, it is very easy for attackers to guess the sequence of pseudo-
random number generators, and for some applications this is not accept‐
able. So instead, we must try to gather "environmental noise" from the
computer's environment, which must be hard for outside attackers to
observe, and use that to generate random numbers. In a Unix environment,
this is best done from inside the kernel.
Previous and contemporary random(4) implementations typically used an
"entropy" pool which was processed with a cryptographic hash function
such as MD5. However, at the time of this writing security issues have
been discovered in some of these functions (MD4, MD5, SHA0, SHA1).
This implementation uses a CSPRNG (Cryptographically Secure Pseudo Random
Number Generator) which is continuously reseeded as described above.
The user interface consists of two character devices /dev/random and
/dev/urandom. The /dev/random device is suitable for use when very high
quality randomness is desired (e.g. for key generation). Previous imple‐
mentations of this device attempted to limit the number of returned bytes
based on a guess as to the secureness of the pool. However, this
resulted in the interface being so undependable that most programs just
started using /dev/urandom instead of /dev/random. The current DragonFly
implementation will return all requested bytes but the system reserves
the right in the future to limit the transfer rate to maintain the high
quality of randomness requested.
The /dev/urandom device uses a different and much faster algorithm, but
one which is not considered to be as secure (though for all practical
purposes it probably is good enough).
Root may write entropy to /dev/random to seed the random number generator
only if the securelevel is less than or equal to zero and the
kern.seedenable sysctl is non-zero. A certain degree of entropy is added
by RC scripts during the boot sequence.
FILES
/dev/random
/dev/urandom
SEE ALSOarc4random(3), drand48(3), rand(3), RAND_add(3), RAND_bytes(3),
random(3), rndcontrol(8)HISTORY
The random, urandom files appeared in FreeBSD 2.1.5.
AUTHORS
The current algorithms are implemented by Robin Carey and were ported to
DragonFly by Matthew Dillon.
Mark Murray wrote the rndcontrol(8) utility for FreeBSD.
The IBAA CSPRNG was developed by Bob Jenkins and is used by /dev/random.
The L15 CSPRNG (based on ARC4) was developed by Robin Carey and is used
by /dev/urandom.
BSD October 21, 1995 BSD
