Entropy running low is a frequent and actual problem for me on virtualized or headless servers serving https content. It slows everything, including ssh, to a halt.
You can see your current entropy level, which is probably high due to having a keyboard, with this command:
cat /proc/sys/kernel/random/entropy_avail
You can watch this number drain by reading from /dev/random continuously.
> Entropy running low is a frequent and actual problem for me on virtualized or headless servers serving https content. It slows everything, including ssh, to a halt.
Entropy running low is not an actual problem. AES-CTR doesn't "run out of key".
If your OS's "entropy estimator" is producing small numbers and your userspace applications are using /dev/random, yes, that will degrade your performance. That's the actual problem.
The solution is for the developers of your software to stop using /dev/random, wholesale.
Saying that the actual problem is "entropy running low" is like saying "water is flammable". That might be true in extreme cases, but isn't in the general case.
> If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does.
This is what randombytes_buf() does in libsodium on older Linux kernels.
This is actually the best of both worlds: Although /dev/urandom on Linux will happily give you predictable values if you try to read from it before the RNG has been seeded on first boot, once /dev/random is "ready" to be read from once, you know that the entropy pool powering /dev/urandom has been seeded. And then you can guarantee that /dev/urandom is secure and nonblocking henceforth.
If you can't just use getrandom(2), do the "poll /dev/random, then read /dev/urandom" dance and even the fearmonger's favorite issue to cite becomes a non-issue.
I don't think using poll on /dev/random is a good idea, here's why:
1. /proc/sys/kernel/random/read_wakeup_threshold is 64 by default [1,2],
but the kernel only considers the pool initialized with >128 bits
[3]. So in an early userspace you're likely to be reading from an uninitialized
/dev/urandom after waking up from poll if you're not also checking
the entropy count to be >128.
2. /dev/random could be a symlink to /dev/urandom, so the call to poll
would return as soon as possible.
3. The system could only be providing /dev/urandom.
So if you're going to have to check the entropy count anyway, a less
convoluted approach would be to repeatedly retrieve it via the
RNDGETENTCNT ioctl [1] on a /dev/urandom file descriptor and sleeping
while it hasn't reached >128 bits yet.
Don't take my word for the feasibility of this fallback method as I'm
not a cryptographer or implementer of cryptographic interfaces. Instead,
consider BoringSSL (Adam Langley et al.) that does almost the same in
its /dev/urandom fallback. [4]
You can see your current entropy level, which is probably high due to having a keyboard, with this command:
cat /proc/sys/kernel/random/entropy_avail
You can watch this number drain by reading from /dev/random continuously.
http://www.issihosts.com/haveged/ Haveged has existed since 2003 and has lots of documentation and discussion of its randomness.