Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
RANDOM(4)	       FreeBSD Kernel Interfaces Manual		     RANDOM(4)

     random -- the entropy device

     device random
     options RANDOM_LOADABLE
     options RANDOM_ENABLE_UMA

     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

     This initial seeding of random number generators is a bootstrapping prob-
     lem that needs very careful attention.  In	some cases, it may be diffi-
     cult 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) criti-
     cally 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	com-
     mand 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
     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 en-
     tropy 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 har-
     vesting of	entropy.

     When options RANDOM_LOADABLE is used, the /dev/random device is not cre-
     ated 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 ob-
     tain 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 ex-
     perimenting and measurement using tools such as dtrace(1) will be re-

     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 in-
     formation 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 random-
     ness.  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	soft-
     ware and games.  The first	requirement of these applications is that the
     random numbers produced conform to	some well-known, usually uniform, dis-
     tribution.	 The sequence of numbers should	also appear numerically	uncor-
     related, 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 ran-
     dom 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 exam-
     ple, 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 in-
     teger 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 repro-
     ducibility	of the sequence	is unimportant,	unlike the previous cases.

     FreeBSD does also provide the traditional rand(3) library call, for com-
     patibility	purposes.  However, it is known	to be poor for simulation and
     absolutely	unsuitable for cryptographic purposes, so its use is discour-


     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

     A random device appeared in FreeBSD 2.2.  The current software implemen-
     tation, introduced	in FreeBSD 10.0, is by Mark R V	Murray,	and is an im-
     plementation 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 depre-

FreeBSD	13.0			August 17, 2015			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help