| haveged(8) | SYSTEM ADMINISTRATION COMMANDS | haveged(8) |
haveged - Generate random numbers and feed Linux's random device.
haveged [options]
haveged generates an unpredictable stream of random numbers harvested from the indirect effects of hardware events on hidden processor state (caches, branch predictors, memory translation tables, etc) using the HAVEGE (HArdware Volatile Entropy Gathering and Expansion) algorithm. The algorithm operates in user space, no special privilege is required for file system access to the output stream.
Linux pools randomness for distribution by the /dev/random and /dev/urandom device interfaces. The standard mechanisms of filling the /dev/random pool may not be sufficient to meet demand on systems with high needs or limited user interaction. In those circumstances, haveged may be run as a privileged daemon to fill the /dev/random pool whenever the supply of random bits in /dev/random falls below the low water mark of the device.
haveged tunes itself to its environment and provides the same built-in test suite for the output stream as used on certified hardware security devices. See NOTES below for further information.
The "tot" tests run only at initialization - there are no negative performance consequences except for a slight increase in the time required to initialize. The "tot" tests guarantee haveged has initialized properly. The use of both test procedures in the "tot" test is highly recommended because the two test emphasize different aspects of RNG quality.
In continuous testing, the test sequence is cycled repeatedly. For example, the string "tbca8b" (suitable for an AIS NTG.1 device) would run procedure B for the "tot" test, then cycle between procedure A8 and procedure B continuously for all further output. Continuous testing does not come for free, impacting both throughput and resource consumption. Continual testing also opens up the possibility of a test failure. A strict retry procedure recovers from spurious failure in all but the most extreme circumstances. When the retry fails, operation will terminate unless a "w" has been appended to the test token to make the test advisory only. In our example above, the string "tbca8wbw" would make all continuous tests advisory. For more detailed information on AIS retries see NOTES below.
Complete control over the test configuration is provided for flexibility. The defaults (ta8bcb" if run as a daemon and "ta8b" otherwise) are suitable for most circumstances.
n = 0 Run as daemon - must be root. Fills /dev/random when the
supply of random bits
falls below the low water mark of the device.
n = 1 Display configuration info and terminate.
n > 1 Write <n> kb of output. Deprecated (use --number instead), only provided for backward compatibility.
If --number is specified, values other than 0,1 are ignored. Default is 0.
1=Show build/tuning summary on termination, summary for online test retries.
2=Show online test retry details
4=Show timing for collections
8=Show collection loop layout
16=Show collection loop code offsets
32=Show all online test completion detail
64=Show info on RNDADDENTROPY operation
Default is 0. Use -1 for all diagnostics.
haveged tunes the HAVEGE algorithm for maximum effectiveness using a hierarchy of defaults, command line options, virtual file system information, and cpuid information where available. Under most circumstances, user input is not required for excellent results.
Run-time testing provides assurance of correct haveged operation. The run-time test suite is modeled upon the AIS-31 specification of the German Common Criteria body, BIS. This specification is typically applied to hardware devices, requiring formal certification and mandated start-up and continuous operational testing. Because haveged runs on many different hardware platforms, certification cannot be a goal, but the AIS-31 test suite provides the means to assess haveged output with the same operational tests applied to certified hardware devices.
AIS test procedure A performs 6 tests to check for statistically inconspicuous behavior. AIS test procedure B performs more theoretical tests such as checking multi-step transition probabilities and making an empirical entropy estimate. Procedure A is the much more resource and compute intensive of the two but is still recommended for the haveged start-up tests. Procedure B is well suited to use of haveged as a daemon because the test entropy estimate confirms the entropy estimate haveged uses when adding entropy to the /dev/random device.
No test is perfect. There is a 10e-4 probability that a perfect generator will fail either of the test procedures. AIS-31 mandates a strict retry policy to filter out false alarms and haveged always logs test procedure failures. Retries are expected but rarely observed except when large data sets are generated with continuous testing. See the libhavege(3) notes for more detailed information.
If running as a daemon, access to the following files is required
/dev/random
/proc/sys/kernel/osrelease
/proc/sys/kernel/random/poolsize
/proc/sys/kernel/random/write_wakeup_threshold
Haveged returns 0 for success and non-zero for failure. The failure return code is 1 "general failure" unless execution is terminated by signal <n>, in which case the return code will be 128 + <n>. The following diagnostics are issued to stderr upon non-zero termination:
Cannot fork into the background
HArdware Volatile Entropy Gathering and Expansion: generating unpredictable random numbers at user level by A. Seznec, N. Sendrier, INRIA Research Report, RR-4592, October 2002
A proposal for: Functionality classes for random number generators by W. Killmann and W. Schindler, version 2.0, Bundesamt fur Sicherheit in der Informationstechnik (BSI), September, 2011
A Statistical Test Suite for the Validation of Random NUmber Generators and Pseudorandom Number Generators for Cryptographic Applications, special publication SP800-22, National Institute of Standards and Technology, revised April, 2010
Additional information can also be found at http://www.issihosts.com/haveged/
Gary Wuertz <gary@issiweb.com> and Jirka Hladky <hladky jiri AT gmail DOT com>
| February 10, 2014 | version 1.9 |