What do you interpret the output of `cat /proc/sys/kernel/random/entropy_avail` to mean?

Nothing.

> There is also no such thing as "running out of entropy".

Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state.

> I don't think this "PRNG" vs. "RNG" distinction is doing us much good.

But it's still nice to seed and periodically reseed a PRNG w/ entropy from an RNG. So there is a distinction between PRNG and RNG to be made, and we should make it. What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.

> Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state.

Yes, of course. PRNG's are about producing random data from a seed. But /dev/random & /dev/urandom isn't just a PRNG.

> What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.

Which is effectively what is going on with /dev/random & /dev/urandom

At the point where you're simply equating /dev/random and /dev/urandom, you're no longer really disagreeing with anybody here. The only difference between the two is that /dev/random keeps a metric on how many bits its vended, and blocks waiting for rekeying when that metric gets too high. That's more or less a nonsensical thing to do.

I'm definitely not saying what /dev/random does makes sense. ;-)

I think I understand what you were getting at by "there is no such thing as running out of entropy". Would you say there is such thing as "not having adequate entropy"?

Not really. A CSPRNG is either initialized properly or it isn't. Once it is, entropy has ceased to be a concern. The original LRNG design misapprehends the purpose of continuous "entropy collection", which is about post-compromise security (it's essentially a rekeying operation), and not about any kind of cryptographic exhaustion.

But /dev/urandom will provide you with random numbers even if initialization has not completed, whereas /dev/random will not.

It's best to think of this as an OS/distro detail; if you can reasonably expect /dev/urandom to give you insecure bits, your distro has a vulnerability.

That said: today you'd just use some variant of getrandom.

> It's best to think of this as an OS/distro detail; if you can reasonably expect /dev/urandom to give you insecure bits, your distro has a vulnerability.

Isn't that more a function of hardware than software? The hardware random number generators on modern CPUs pretty much eliminate the need to worry about entropy...

No, this has nothing at all to do with hardware; the state of play is the same on machines that don't have instructions like RDRAND.

I think I still don't understand. Can you explain why it is not a hypothetical problem on a deterministic virtual machine?