Provided by: freebsd-manpages_10.1~RC1-1_all 
NAME
random — the entropy device
SYNOPSIS
device random
DESCRIPTION
The random device returns an endless supply of random bytes when read. It also accepts and reads data as
any ordinary (and willing) file, but discards data written to it. The device will probe for certain
hardware entropy sources, and use these in preference to the fallback, which is a generator implemented in
software.
The software generator will start in an unseeded state, and will block reads until it is (re)seeded. This
may cause trouble at system boot when keys and the like are generated from /dev/random so steps should be
taken to ensure a reseed as soon as possible. The sysctl(8) controlling the seeded status (see below) may
be used if security is not an issue or for convenience during setup or development.
This initial seeding of random number generators is a bootstrapping problem that needs very careful
attention. In some cases, it may be difficult to find enough randomness to seed a random number generator
until a system is fully operational, but the system requires random numbers to become fully operational.
It is (or more accurately should be) critically important that the random device is seeded before the first
time it is used. In the case where a dummy or "blocking-only" device is used, it is the responsibility of
the system architect to ensure that no blocking reads hold up critical processes.
To see the current settings of the software random device, use the command line:
sysctl kern.random
which results in something like:
kern.random.adaptors: yarrow,dummy
kern.random.active_adaptor: yarrow
kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 96
kern.random.yarrow.slowthresh: 128
kern.random.yarrow.slowoverthresh: 2
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 1
kern.random.sys.harvest.point_to_point: 1
kern.random.sys.harvest.interrupt: 1
kern.random.sys.harvest.swi: 1
Other than
kern.random.adaptors
all settings are read/write.
The kern.random.sys.seeded variable indicates whether or not the random device is in an acceptably secure
state as a result of reseeding. If set to 0, the device will block (on read) until the next reseed as a
result of entropy harvesting. A reseed will set the value to 1 (non-blocking).
The kern.random.sys.harvest.ethernet variable is used to select LAN traffic as an entropy source. A 0
(zero) value means that LAN traffic is not considered as an entropy source. Set the variable to 1 (one) if
you wish to use LAN traffic for entropy harvesting.
The kern.random.sys.harvest.point_to_point variable is used to select serial line traffic as an entropy
source. (Serial line traffic includes PPP, SLIP and all tun0 traffic.) A 0 (zero) value means such
traffic is not considered as an entropy source. Set the variable to 1 (one) if you wish to use it for
entropy harvesting.
The kern.random.sys.harvest.interrupt variable is used to select hardware interrupts as an entropy source.
A 0 (zero) value means hardware interrupts are not considered as an entropy source. Set the variable to 1
(one) if you wish to use them for entropy harvesting. All hardware interrupt harvesting is set up by the
individual device drivers.
The kern.random.sys.harvest.swi variable is used to select software interrupts as an entropy source. A 0
(zero) value means software interrupts are not considered as an entropy source. Set the variable to 1
(one) if you wish to use them for entropy harvesting.
The other variables are explained in the paper describing the Yarrow algorithm at
http://www.schneier.com/yarrow.html.
These variables are all limited in terms of the values they may contain:
kern.random.yarrow.gengateinterval [4..64]
kern.random.yarrow.bins [2..16]
kern.random.yarrow.fastthresh [64..256]
kern.random.yarrow.slowthresh [64..256]
kern.random.yarrow.slowoverthresh [1..5]
Internal sysctl(3) handlers force the above variables into the stated ranges.
RANDOMNESS
The use of randomness in the field of computing is a rather subtle issue because randomness means different
things to different people. Consider generating a password randomly, simulating a coin tossing experiment
or choosing a random back-off period when a server does not respond. Each of these tasks requires random
numbers, but the random numbers in each case have different requirements.
Generation of passwords, session keys and the like requires cryptographic randomness. A cryptographic
random number generator should be designed so that its output is difficult to guess, even if a lot of
auxiliary information is known (such as when it was seeded, subsequent or previous output, and so on). On
FreeBSD, seeding for cryptographic random number generators is provided by the random device, which
provides real randomness. The arc4random(3) library call provides a pseudo-random sequence which is
generally reckoned to be suitable for simple cryptographic use. The OpenSSL library also provides
functions for managing randomness via functions such as RAND_bytes(3) and RAND_add(3). Note that OpenSSL
uses the random device for seeding automatically.
Randomness for simulation is required in engineering or scientific software and games. The first
requirement of these applications is that the random numbers produced conform to some well-known, usually
uniform, distribution. The sequence of numbers should also appear numerically uncorrelated, as simulation
often assumes independence of its random inputs. Often it is desirable to reproduce the results of a
simulation exactly, so that if the generator is seeded in the same way, it should produce the same results.
A peripheral concern for simulation is the speed of a random number generator.
Another issue in simulation is the size of the state associated with the random number generator, and how
frequently it repeats itself. For example, a program which shuffles a pack of cards should have 52!
possible outputs, which requires the random number generator to have 52! starting states. This means the
seed should have at least log_2(52!) ~ 226 bits of state if the program is to stand a chance of outputting
all possible sequences, and the program needs some unbiased way of generating these bits. Again, the
random device could be used for seeding here, but in practice, smaller seeds are usually considered
acceptable.
FreeBSD provides two families of functions which are considered suitable for simulation. The random(3)
family of functions provides a random integer between 0 to (2**31)−1. The functions srandom(3),
initstate(3) and setstate(3) are provided for deterministically setting the state of the generator and the
function srandomdev(3) is provided for setting the state via the random device. The drand48(3) family of
functions are also provided, which provide random floating point numbers in various ranges.
Randomness that is used for collision avoidance (for example, in certain network protocols) has slightly
different semantics again. It is usually expected that the numbers will be uniform, as this produces the
lowest chances of collision. Here again, the seeding of the generator is very important, as it is required
that different instances of the generator produce independent sequences. However, the guessability or
reproducibility of the sequence is unimportant, unlike the previous cases.
FreeBSD does also provide the traditional rand(3) library call, for compatibility purposes. However, it is
known to be poor for simulation and absolutely unsuitable for cryptographic purposes, so its use is
discouraged.
FILES
/dev/random
SEE ALSO
arc4random(3), drand48(3), rand(3), RAND_add(3), RAND_bytes(3), random(3), sysctl(8)
HISTORY
A random device appeared in FreeBSD 2.2. The early version was taken from Theodore Ts'o's entropy driver
for Linux. The current software implementation, introduced in FreeBSD 5.0, is a complete rewrite by Mark R
V Murray, and is an implementation of the Yarrow algorithm by Bruce Schneier, et al. Significant
infrastructure work was done by Arthur Mesh.
The author gratefully acknowledges significant assistance from VIA Technologies, Inc.