Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

ENTROPY(7)             Miscellaneous Information Manual             ENTROPY(7)

NAME
     entropy - random unpredictable secrets needed for security

DESCRIPTION
     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
     random number generators based on thermal noise in silicon circuits,
     others may require operator intervention for security.

   Threats
     ⊕   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
         adversary 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
     unpredictable 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
     automatically 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
         booting to multiuser (with the caveat that it may cause boot to hang
         forever).

     Since it is difficult to confidently model the unpredictability of most
     physical systems, only devices specifically designed to be hardware
     random 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
     virtualization 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.

   Adding entropy
     You can manually save and load seeds with the rndctl(8) tool.  For
     example, 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
           /etc/rc.d/random_seed stop
     on the target machine to ensure that the entropy will be saved for next
     boot, even if the system later 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
     running:
           echo thttthhhhttththtttht... > /dev/urandom
     Then run
           /etc/rc.d/random_seed stop
     to ensure that the effort will be saved for next boot.

     Inputs from the superuser (uid 0) to /dev/urandom count toward the
     system'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
     little 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).

DIAGNOSTICS
     NetBSD may print the following warnings to the console:

           WARNING: system needs entropy for security; see entropy(7)  Some
           process tried to draw use entropy from NetBSD, e.g. to generate a
           key for cryptography, before enough inputs from reliable entropy
           sources have been obtained.  The entropy may be low enough that an
           adversary could guess keys by brute force.

           This message is rate-limited, so if you have added entropy and want
           to verify that the problem is resolved, you should consult the
           kern.entropy.needed sysctl(7) variable to confirm it is zero,
           rather than just look for the absence of this message; see rnd(4)
           for details.

SEE ALSO
     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,
     https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger,
     https://factorable.net/, 205-220, August 2012.

     openssl -- predictable random number generator, Debian Security Advisory,
     https://www.debian.org/security/2008/dsa-1571.html, 2008-05-13,
     DSA-1571-1.

     Features/VirtIORNG, QEMU Wiki, https://wiki.qemu.org/Features/VirtIORNG,
     2016-10-17.

NetBSD 9.99                     January 4, 2021                    NetBSD 9.99