- NetBSD Manual Pages
ENTROPY(7) NetBSD Miscellaneous Information Manual ENTROPY(7)
Powered by man-cgi (2020-09-24).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.
entropy -- random unpredictable secrets needed for security
Computers need random unpredictable secrets for the security of software
such as web browsers and ssh(1).
Computers are designed to behave in highly predictable ways, so they rely
on observations of random physical phenomena around them, called entropy
sources, to derive unpredictable secrets for cryptography.
While some computers have reliable entropy sources such as hardware ran-
dom number generators based on thermal noise in silicon circuits, others
may require operator intervention for security.
· Web browsers and programs such as ssh(1) rely on unpredictable
secrets in cryptography to prevent eavesdropping and detect tampering
of sessions over the network.
· ssh-keygen(1) relies on unpredictable secrets to create keys that
allow you to log in but keep out malicious adversaries; if an adver-
sary could guess the key then they could impersonate you.
· NetBSD relies on unpredictable secrets to make sure that private user
data stored on nonvolatile media when memory is scarce (swapctl(8),
using `vm.swap_encrypt=1'; see sysctl(7)) cannot be recovered by
forensic tools after shutdown.
Entropy in NetBSD
NetBSD gathers samples from various kinds of entropy sources, including:
· hardware random number generators
· network traffic timing
· user input (keystrokes, mouse movements, etc.)
· disk I/O latency
· environment sensors (envsys(4))
The samples are mixed together with cryptography to yield unpredictable
secrets through /dev/urandom (see rnd(4)) and related interfaces used by
programs like ssh(1), Firefox, and so on.
NetBSD also stores a random seed at /var/db/entropy-file to carry unpre-
dictable secrets over from one boot to the next, as long as the medium
remains secret and can be updated on boot. The seed is maintained auto-
matically by /etc/rc.d/random_seed (see rc.conf(5)).
Ensuring enough entropy
Entropy is measured in bits, and only 256 bits of entropy are needed for
security, thanks to modern cryptography.
To detect potentially insecure systems, NetBSD records how many bits it
needs to achieve the full 256 bits, exposed via the sysctl(7) variable
kern.entropy.needed, and takes measures to alert the operator if there
isn't definitely enough for security:
· NetBSD issues warnings on the console if there's not enough entropy
when programs need it; see rnd(4).
· The daily security report includes an alert if there's not enough
entropy; see security.conf(5).
· The operator can set `entropy=check' in rc.conf(5) so that NetBSD
will refuse to boot to multiuser unless there is enough entropy, or
set `entropy=wait' so that NetBSD will wait for entropy before boot-
ing to multiuser (with the caveat that it may cause boot to hang for-
Since it is difficult to confidently model the unpredictability of most
physical systems, only devices specifically designed to be hardware ran-
dom number generators count toward NetBSD's estimate of the entropy.
Many new computers have hardware random number generators, such as
RDRAND/RDSEED in Intel/AMD CPUs, or ARMv8.5-RNDRRS; virtio(4)-based vir-
tualization platforms such as QEMU can expose entropy from the host with
viornd(4); bootloader firmware such as UEFI may also expose an underlying
platform's random number generator.
However, many older computers have no reliable entropy sources. Some
have the hardware, but have it off by default, such as a disabled tpm(4).
On computers with no built-in reliable entropy source, you may wish to
transfer a seed from another computer with rndctl(8), or manually enter
samples into /dev/urandom -- see below.
You can manually save and load seeds with the rndctl(8) tool. For exam-
ple, you might use
rndctl -S seed
to save a seed from one machine, transfer it over a medium where you are
confident there are no eavesdroppers to another machine, and load it with
rndctl -L seed
on the target machine; then run
on the target machine to ensure that the entropy will be saved for next
boot, even if the system crashes or otherwise shuts down uncleanly.
rndctl -S records the number of bits of entropy in the seed so that
rndctl -L can count it.
Users can write data to /dev/urandom to be mixed together with all other
samples. For example, no matter what entropy sources are built into a
computer, you can ensure it has enough entropy (as long as there are no
surveillance cameras watching you) by flipping a coin 256 times and run-
echo thttthhhhttththtttht... > /dev/urandom
to ensure that the effort will be saved for next boot.
Inputs from the superuser (uid 0) to /dev/urandom count toward the sys-
tem's entropy estimate, at the maximum rate of one bit of entropy per bit
of data; inputs from unprivileged users will affect subsequent outputs
but will be counted as having zero entropy.
After adding entropy, make sure to regenerate any long-term keys that
might be predictable because they were previously generated with too lit-
tle entropy. For example, if `sshd=YES' is enabled in /etc/rc.conf, then
NetBSD will automatically generate ssh host keys on boot; if they were
generated with too little entropy, then you may wish to delete them and
create new ones before allowing anyone to log in via ssh(1).
getrandom(2), arc4random(3), rnd(4), rc.conf(5), rc(8), rndctl(8)
Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman,
"Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network
Devices", Proceedings of the 21st USENIX Security Symposium, USENIX,
sessions/presentation/heninger https://factorable.net/, 205-220, August
openssl -- predictable random number generator, Debian Security Advisory,
Features/VirtIORNG, QEMU Wiki, https://wiki.qemu.org/Features/VirtIORNG,
NetBSD 9.99 January 4, 2021 NetBSD 9.99