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.
If the device is using the software generator, writing data to
random would perturb the internal state. This perturbation
of the internal state is the only userland method of introducing extra entropy
into the device. If the writer has superuser privilege, then closing the
device after writing will make the software generator reseed itself. This can
be used for extra security, as it immediately introduces any/all new entropy
into the PRNG. The hardware generators will generate sufficient quantities of
entropy, and will therefore ignore user-supplied input. The software
random device may be controlled with
sysctl(8).
To see the current settings of the software
random device, use
the command line:
sysctl kern.random
which results in something like:
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: 0
kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 192
kern.random.yarrow.slowthresh: 256
kern.random.yarrow.slowoverthresh: 2
(These would not be seen if a hardware generator is present.)
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 (which can be from an explicit write, or 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.counterpane.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.
One final consideration for the seeding of random number generators is a
bootstrapping problem. 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. There is no substitute for careful thought here, but the
FreeBSD random device, which is
based on the Yarrow system, should be of some help in this area.
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.
The only hardware implementation currently is for the VIA C3 Nehemiah
(stepping 3 or greater) CPU. More will be added in the future.
The author gratefully acknowledges significant assistance from VIA Technologies,
Inc.