[slavik81]

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances.

> Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

[technion]

The part of this myth is down to what those circumstances are.

What's generally accepted is that, early during first boot, urandom still produces 'random' data without enough entropy for it to be sufficiently random.

What's a myth is that 'entropy can run out' and somehow a sufficiently seeded CSPRNG needs to block after a few reads while it gathers more entropy.

The problem in these discussions is that one, edge case, but valid concern, becomes a cargo cult of "why you shouldn't use urandom" and introduces a messy anti-pattern.

[rurban]

Which is was exactly described in this paper. It's not cargo cult, it's the exact technical explanation what happens when the entropy runs out, while it should be blocking or in the OpenSSL case just use a proper API to avoid the exact same confusion (this is low entropy as with /dev/urandom ) or add more mixing rounds.

The cargo cult you are describing is exactly the cargo cult trap you are falling into.

[technion]

Question 4 specifically discusses the point tat entropy does not "run out".

[Natanael_L]

Entropy doesn't run out if your CSPRNG is good

[geofft]

One of the very early initscripts (on Debian, /etc/rcS.d/urandom or /lib/systemd/system/urandom.service, both of which happen well before normal initscripts) restores a random seed that was saved at last shutdown.

After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swap -- so if you're writing code that needs to run there, you hopefully know that the system is in a weird state. And if you're writing something that runs a service that needs secure random numbers that early in the boot process, you're definitely doing something nonstandard and possibly misguided, and it's reasonable for the burden to be on you to take appropriate precautions, or switch to doing something normal.

For normal application developers, who tend to wait until after the network is up to interact with the network, this special case doesn't apply.

[slavik81]

The usual time I've been concerned has been after creating a new virtual machine. Right after creating a new DO droplet I need to do a bunch of things to set up my application, like seed my CSRF token generator.

Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.

[geofft]

Ugh, yes, the practice of short-lived machines throws off the assumption of "when it was last shut down." You are totally right that this is a concern.

The ideal solution to this would be for hypervisors to just pass a random seed to their guests. (There is even a full virtio-rng device in qemu, it just seems to have /dev/random semantics from a quick glance.) I don't know how we get to the point of convincing the big cloud providers to start doing this, though.

[jasonvorhe]

Wouldn't it help to run something like havaged on the virtualization host that's feeding entropy to the virtualized nodes?

[jquast]

yes