It isn’t an “awful security regression”. That isn’t how the CSPRNG works. Once you initially seed the RNG it is suitable for cryptographic applications — reseeding adds some forward secrecy but isn’t really needed. The premise behind the CSPRNG is that cryptography isn’t broken, and the only applications that require cryptographically secure numbers are cryptography.
That article while intended to argue “pro /dev/urandom” is actually quite eloquent on why not do do that. Quoting from the article:
Since at least the early 2000s, Linux distributions have applied workarounds to ensure proper entropy at boot time, namely that a boot script injects the contents of a saved file upon boot, and immediately proceeds to regenerate the said file with /dev/urandom. In effect, this transports the entropy across reboots, so that even if the boot sequence was not enough, by itself, to generate enough entropy, the file contents would ensure that everything is all right.
Yes, great but we should scrutinize if that is working. Known cases where systemd-random-seed.service approaches (restore from previously saves entropy seed file) don’t work is the first boot, read-only media (Live DVD)
Article goes on…
there are times when the entropy pool is really empty, namely during the early stages of the boot. At that point, the kernel did not obtain many physical events to work on, and it is conceivable that /dev/urandom output could be predicted.
Exactly this is an issue. So, avoid /dev/urandom, use /dev/random and perhaps getrandom(2) (depending on kernel version).
There are now a few extra relevant points to make:
Virtual machines are a challenge to entropy gathering, in at least three ways:
They provided access to virtual, emulated hardware only. The nice physical events from which entropy is supposed to come (thermal noise, mostly) are then just a simulation, and that which is simulated can, indeed, be simulated.
The hypervisor can prevent access to the cycle counter (rdtsc opcode), which will further hinder attempts by the kernel to get entropy from the (not so) physical events.
VM snapshots can be taken and replayed at will; each restart from the same snapshot will use the recorded pool contents.
Indeed. We should make sure that such issues are handled as best as possible.
A contrario, sufficiently recent CPU have an embedded hardware generator which is totally available from VM (it’s the rdrand opcode on x86 CPU). The Linux kernel uses rdrand. It does not trust rdrand, because NSA (I’m not exaggerating! The kernel source code explicitly calls out the NSA), so it will not count the rdrand output as worth any entropy. But it will still use it. In all edge cases described above (network boot, VM snapshots…), rdrand will by itself ensure that there is enough entropy for all practical purposes.
The kernel in Debian by default trusts / enables / “credits” entropy by RDRAND by default since Debian buster. I added the reference here: RDRAND
The reference contains links that make the case why RDRAND should not be trusted.
Whonix / security-misc flips the setting to “distrust” RDRAND, disables that entropy from RDRAND are “credited”. In other words, in RDRAND is not “credited” in Whonix. (RDRAND isn’t fully disabled which I am not sure is possible, wasn’t suggested and should not be an issue if the kernel theory holds true that even malicious entropy sources are OK if mixed with legitimate entropy sources).
I’ve recently made the argument at Qubes to “distrust” (which means actually just “don’t credit”) RDRAND at Qubes:
Since RDRAND conceptually cannot be the only solution we should look more. → Moar Entropy Sources
the early boot moments we are talking about are before there is any notion of a file; this is really about a single case, which is booting a diskless machine over the network, and mounting the root filesystem from a remote server. The relevant network protocol can need some randomness (e.g. TCP sequence numbers).
I don’t like that.
Should be only done securely and block if necessary blocking by default, or
opt-in, non-blocking, known security risks.
Should be no in between “maybe random, maybe predictable” at any time.
The critical issue is “Once”. If it is conceivable that [random source] output could be predicted in any corner case, that’s an awful security regression.
We performed a large-scale study of RSA and DSA cryptographic keys in use on the Internet and discovered that significant numbers of keys are insecure due to insufficient randomness.
Most critically, we found that the Linux random number generator can produce predictable output at boot under certain conditions,