> Using the Jitter RNG core, the rngd provides an entropy source that feeds into the Linux /dev/random device if its entropy runs low. It updates the /dev/random entropy estimator such that the newly provided entropy unblocks /dev/random.
They made a very questionable decision based on the sort of ignorance that leads people to use /dev/random and haveged rather than RtlGenRandom (Windows), getrandom(2) (new Linux), or /dev/urandom (old Linux).
Cryptography engineering requires care and this sort of ignorance tends to undermine secure implementations.
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]
At the risk of getting downvoted for this, I urged caution against VeraCrypt in the past, because of the ties the company of its developer (IDRIX) has with the French government, lack of a history in cryptography before he took over VeraCrypt, and the overall possibility of nearness to the French security apparatus. People say that you can audit the code and compile it on your own, but who does that? Who checks the binaries?
To me with my overly vivid imagination, the fast forking of TrueCrypt to VeraCrypt looked like a hasty power grab by DGSE. Pure speculation, though.
The problem is that a design decision like this calls into question the competence of the developers, and therefore the safety of any modifications they've made in the past.
> Using the Jitter RNG core, the rngd provides an entropy source that feeds into the Linux /dev/random device if its entropy runs low. It updates the /dev/random entropy estimator such that the newly provided entropy unblocks /dev/random.
This is a red flag. Entropy doesn't run low. https://www.2uo.de/myths-about-urandom
I'm calling it now: Don't use VeraCrypt.
They made a very questionable decision based on the sort of ignorance that leads people to use /dev/random and haveged rather than RtlGenRandom (Windows), getrandom(2) (new Linux), or /dev/urandom (old Linux).
Cryptography engineering requires care and this sort of ignorance tends to undermine secure implementations.