Internal sysctl(3) handlers force the above variables into the stated ranges.
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
.Fx , 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.
.Fx provides two families of functions which are considered suitable for simulation. The random(3) family of functions provides a random integer between 0 to 2310-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.
.Fx 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.
arc4random(3), drand48(3), rand(3), RAND_add(3), RAND_bytes(3), random(3), sysctl(8)
A random device appeared in
.Fx 2.2 . The early version was taken from Theodore Tsos entropy driver for Linux. The current software implementation, introduced in
.Fx 5.0 , is a complete rewrite by
.An 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.