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

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
RANDOM(4)	       FreeBSD Kernel Interfaces Manual		     RANDOM(4)

NAME
     random -- the entropy device

SYNOPSIS
     device random

DESCRIPTION
     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
	   kern.random.adaptors
     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
     serial 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
     interrupt harvesting is set up by the individual device drivers.

     The kern.random.sys.harvest.swi variable is used to select	software
     interrupts	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
     algorithm at http://www.schneier.com/yarrow.html.

     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
     ranges.

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 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
     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 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-
     aged.

FILES
     /dev/random

SEE ALSO
     arc4random(3), drand48(3),	rand(3), RAND_add(3), RAND_bytes(3),
     random(3),	sysctl(8)

HISTORY
     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
     implementation, 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
     Mesh.

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

FreeBSD	10.1		       October 12, 2013			  FreeBSD 10.1

NAME | SYNOPSIS | DESCRIPTION | RANDOMNESS | FILES | SEE ALSO | HISTORY

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4&manpath=FreeBSD+10.0-RELEASE>

home | help