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.

     If	the device is using the	software generator, writing data to random
     would perturb the internal	state.	This perturbation of the internal
     state is the only userland	method of introducing extra entropy into the
     device.  If the writer has	superuser privilege, then closing the device
     after writing will	make the software generator reseed itself.  This can
     be	used for extra security, as it immediately introduces any/all new en-
     tropy into	the PRNG.  The hardware	generators will	generate sufficient
     quantities	of entropy, and	will therefore ignore user-supplied input.
     The software random device	may be controlled with sysctl(8).

     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.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:	0
	   kern.random.yarrow.gengateinterval: 10
	   kern.random.yarrow.bins: 10
	   kern.random.yarrow.fastthresh: 192
	   kern.random.yarrow.slowthresh: 256
	   kern.random.yarrow.slowoverthresh: 2

     (These would not be seen if a hardware generator is present.)

     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 (which	can be
     from an explicit write, or	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.

     One final consideration for the seeding of	random number generators is a
     bootstrapping problem.  In	some cases, it may be difficult	to find	enough
     randomness	to seed	a random number	generator until	a system is fully op-
     erational,	but the	system requires	random numbers to become fully opera-
     tional.  There is no substitute for careful thought here, but the FreeBSD
     random device, which is based on the Yarrow system, should	be of some
     help in this area.

     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.  The only	hardware implementation	currently is for the
     VIA C3 Nehemiah (stepping 3 or greater) CPU.  More	will be	added in the

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

BSD				 July 19, 2006				   BSD


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

home | help