Provided by: freebsd-manpages_8.2-1_all bug

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.