ENTROPY(7)

📦 version 11.0, in nixpkgs unstable

💫 ENTROPY(7) 💫

okay so this is the entropy(7) page from the Miscellaneous Information Manual, and honestly bestie, it's lowkey one of the most important pages you'll ever read, because it's all about random unpredictable secrets needed for security and that's the whole vibe of modern crypto. 🎀

✨ NAME ✨

entropy — random unpredictable secrets needed for security 🦋

🌸 DESCRIPTION 🌸

So like. Computers need random unpredictable secrets for the security of software such as web browsers and ssh(1). That's just the tea. ☕

But here's the thing — computers are designed to behave in highly predictable ways, which is iconic for reproducibility and absolutely terrible for secrecy. So they rely on observations of random physical phenomena around them, called entropy sources, to derive unpredictable secrets for cryptography. It's giving "chaos is the blueprint" honestly. 🌪️

Some computers have reliable entropy sources — like hardware random number generators based on thermal noise in silicon circuits, which is so main character — but others may require operator intervention for security. Yeah. You. You're the operator. 🫵

💀 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. No eavesdroppers allowed, periodt. 🙅‍♀️
  • 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. And like… not the impersonation arc we're going for. 😭
  • 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. So your swap doesn't snitch on you after you dip. 💅

🧚 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. Bestie they're all sipping from the same unpredictable straw and that's the point. 🥤

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)). It's literally the "remember me" checkbox but for entropy. ✨

🔥 Ensuring enough entropy 🔥

Entropy is measured in bits, and only 256 bits of entropy are needed for security, thanks to modern cryptography. That's it. That's the number. 256. Slay. 👑

To detect potentially insecure systems, NetBSD 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). It's giving concerned friend energy. 🫶
  • The motd(5) has a warning if there was not enough entropy when network daemons such as sshd(8) first generated keys. The message of the day is officially the message of concern.
  • The daily security report includes an alert if there's still not enough entropy; see security.conf(5). Daily drama report, honestly.

Since it is hard to know how unpredictable most physical systems are, only devices specifically designed to be hardware random number generators, or a seed file stored on disk, count toward these alerts. Like, only the certified-unpredictable girlies count. No posers. 🚫

At boot, NetBSD will wait, when 'entropy=wait' is set in rc.conf(5), or fail to single-user mode, when 'entropy=check' is set, if there is not enough entropy from any sources — including devices not designed to be unpredictable, such as the CPU cycle counter sampled by a periodic timer — provided the samples pass a simple filter called the 'entropy estimator', like other operating systems. So yeah, even the sketchy sources get a vibe check from the estimator. 🕵️‍♀️

Sources known to be predictable, which could give a false sense of security, can be disabled from unblocking boot by setting rndctl_flags in rc.conf(5). Translation: if a source is a known liar, you can literally tell it to stop holding up the line at boot. 💅

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. New hardware is eating in the entropy department, no cap. 🔥

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). Tragic. They have the gift and refuse to use it. 💀

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. Yes we're going there. 👇

🍓 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. It's literally a little care package of chaos. 🎁

Bestie — that transfer medium part is not a joke. You want no eavesdroppers. Treat that seed like your most private group chat. 🔒

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. Yes, that's genuine physical-coin-flipping sweat equity going straight into the kernel. Iconic behavior, honestly. 🪙

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. So like… root gets credit, everyone else gets vibes only. 🙈

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). Old weak keys are not the moment. Delete and re-do. 🗑️✨

🌈 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. That is so not the vibe — brute-forceable keys are the enemy of the people. 😭

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. Do not — I repeat, do not — just assume silence means fixed. Check the actual number. Periodt. 💅

👑 SEE ALSO 👑

getrandom(2), arc4random(3), rnd(4), rc.conf(5), rc(8), rndctl(8)

And now the reading list, because the references are honestly a whole curriculum:

🌸 and that's the page, bestie 🌸 — this one comes to you from the Debian crew, dated June 30, 2023, and it lives in section ENTROPY(7). Go forth and be unpredictable, fr fr. 💜🦋

📦 where this page comes from