Provided by: freebsd-manpages_11.1-3_all bug

NAME

     random — the entropy device

SYNOPSIS

     device random
     options RANDOM_LOADABLE
     options RANDOM_ENABLE_UMA

DESCRIPTION

     The random device returns an endless supply of random bytes when read.  It also accepts and
     reads data as any ordinary file.

     The generator will start in an unseeded state, and will block reads until it is seeded for
     the first time.  This may cause trouble at system boot when keys and the like are generated
     from random so steps should be taken to ensure a seeding as soon as possible.

     It is also possible to read random bytes by using the KERN_ARND sysctl.  On the command line
     this could be done by

           sysctl -x -B 16 kern.arandom

     This sysctl will not return random bytes unless the random device is seeded.

     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.fortuna.minpoolsize: 64
           kern.random.harvest.mask_symbolic: [HIGH_PERFORMANCE], ... ,CACHED
           kern.random.harvest.mask_bin: 00111111111
           kern.random.harvest.mask: 511
           kern.random.random_sources: 'Intel Secure Key RNG'

     Other than
           kern.random.fortuna.minpoolsize
     and
           kern.random.harvest.mask
     all settings are read-only.

     The kern.random.fortuna.minpoolsize sysctl is used to set the seed threshold.  A smaller
     number gives a faster seed, but a less secure one.  In practice, values between 64 and 256
     are acceptable.

     The kern.random.harvest.mask bitmask is used to select the possible entropy sources.  A 0
     (zero) value means the corresponding source is not considered as an entropy source.  Set the
     bit to 1 (one) if you wish to use that source.  The kern.random.harvest.mask_bin and
     kern.random.harvest.mask_symbolic sysctls can be used to confirm that the choices are
     correct.  Note that disabled items in the latter item are listed in square brackets.  See
     random_harvest(9) for more on the harvesting of entropy.

     When options RANDOM_LOADABLE is used, the /dev/random device is not created until an
     "algorithm module" is loaded.  Two of these modules are built by default, random_fortuna and
     random_yarrow.  The random_yarrow module is deprecated, and will be removed in FreeBSD 12.
     Use of the Yarrow algorithm is not encouraged, but while still present in the kernel source,
     it can be selected with the options RANDOM_YARROW kernel option.  Note that these loadable
     modules are slightly less efficient than their compiled-in equivalents.  This is because
     some functions must be locked against load and unload events, and also must be indirect
     calls to allow for removal.

     When options RANDOM_ENABLE_UMA is used, the /dev/random device will obtain entropy from the
     zone allocator.  This is potentially very high rate, and if so will be of questionable use.
     If this is the case, use of this option is not recommended.  Determining this is not
     trivial, so experimenting and measurement using tools such as dtrace(1) will be required.

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),
     random(9)

     Ferguson, Schneier, and Kohno, Cryptography Engineering, Wiley, ISBN 978-0-470-47424-2.

HISTORY

     A random device appeared in FreeBSD 2.2.  The current software implementation, introduced in
     FreeBSD 10.0, is by Mark R V Murray, and is an implementation of the Fortuna algorithm by
     Ferguson et al.  It replaces the previous Yarrow implementation, introduced in FreeBSD 5.0.
     The Yarrow algorithm is no longer supported by its authors, and is therefore deprecated.