Myths about /dev/urandom - Thomas' Digital Garden makes a good argument but I am not totally convinced.
The updated man page random(4) - Linux manual page contradicts itself in my understanding.
When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized.
Doesn’t sound great. Imagine some systemd or other bug where this goes unnoticed.
The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted.
- Ok, so you say it’s legacy.
- I see.
If this is of concern in your application, use getrandom(2) or /dev/random instead.
So not really legacy if /dev/random is still mentioned. Contradiction.
Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.
→ password generator should use getrandom(2) rather than /dev/urandom since quote, “simpler and safer”.
The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.
BUGS
During early boot time, reads from /dev/urandom may return data prior to the entropy pool being initialized.
It is still sounds messy.
Quote Myths about /dev/urandom - Thomas' Digital Garden
FreeBSD does the right thing: they don’t have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won’t block ever again.
That sounds better.
But the discussion is too difficult to make a decision at the Whonix level. Not much we could do here except pointing people at these arguments, making arguments, discussing things upstream.
