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

FreeBSD Manual Pages


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

     random -- the entropy device

     device random

     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.

     The software generator will start in an unseeded state, and will block
     reads until it is (re)seeded.  This may cause trouble at system boot when
     keys and the like are generated from /dev/random so steps should be taken
     to	ensure a reseed	as soon	as possible.  The sysctl(8) controlling	the
     seeded status (see	below) may be used if security is not an issue or for
     convenience during	setup or development.

     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.adaptors: yarrow,dummy
	   kern.random.active_adaptor: yarrow
	   kern.random.yarrow.gengateinterval: 10
	   kern.random.yarrow.bins: 10
	   kern.random.yarrow.fastthresh: 96
	   kern.random.yarrow.slowthresh: 128
	   kern.random.yarrow.slowoverthresh: 2
	   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:	1

     Other than
     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 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 traf-
     fic 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 se-
     rial 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 inter-
     rupts are not considered as an entropy source.  Set the variable to 1
     (one) if you wish to use them for entropy harvesting.  All	hardware in-
     terrupt harvesting	is set up by the individual device drivers.

     The kern.random.sys.harvest.swi variable is used to select	software in-
     terrupts as an entropy source.  A 0 (zero)	value means software inter-
     rupts 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 al-
     gorithm at

     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

     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)

     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 im-
     plementation, 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.  Significant infrastructure work was done	by Arthur

     The author	gratefully acknowledges	significant assistance from VIA	Tech-
     nologies, Inc.

BSD			       October 12, 2013				   BSD


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

home | help