Man

Command Section
RANDOM(4)              FreeBSD Kernel Interfaces Manual              RANDOM(4)

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.

FreeBSD 11.1-RELEASE-p4         August 17, 2015        FreeBSD 11.1-RELEASE-p4
Command Section