[bhickey]

> You need quality entropy to seed a CSPRNG - not quantity.

For the most part I think you're spot on, but I don't follow here. Entropy is measured in bits and bits are bits are bits. When we ask /dev/random for 256-bits it should return a 256-bit sequence, possibly after blocking. If that sequence exhibits less than 256-bits of entropy, it just means that the pool had a bad entropy estimate. Is there some nuance I'm missing?

[qrmn]

The point I'm making is that people should probably balk at the suggestion that they need 200Mbps/sec of entropy from a mysterious black box on a PCIe card sold to them by an NSA affiliate who want them to put it into their critical servers. No. Just... no. Don't do that.

256 good bits, once, is quite enough, as long as they are good. You might well try to collect more entropy, and your CSPRNG's setup might use a compression function (e.g. a cryptographic hash) to combine them into the seed to try to hedge against failures. That's quite a good idea, as long as the last one you sample is your most trusted (see djb's blog for why). But you don't need megabits of entropy, and you don't need it on an ongoing basis. That task is solved by the PRF.

So what you should perhaps be doing is not using /dev/random at all, but using Linux's default getrandom syscall to get 256 bits to seed your userspace CSPRNG instead. The urandom mode of that will block if it hasn't collected enough entropy, and will never block thereafter, and it also doesn't need a device node handy.

Even attempting to estimate entropy is perilous, so most modern CSPRNGs don't try. (Note, by way of example, the difference between the earlier Yarrow and the later Fortuna.)

[PhantomGremlin]

sold to them by an NSA affiliate

So if you're against quantum RNGs you probably won't be buying anything from ID Quantique[1]. I don't know if they're an NSA affiliate. But they are Swiss, and another Swiss company, Crypto AG,[2] reportedly backdoored their crypto at the behest of the NSA.

I don't share your enthusiasm for shot-noise-based RNGs. There's a lot to go wrong there as well.

[1] http://www.idquantique.com/ [2] https://en.wikipedia.org/wiki/Crypto_AG#Back-doored_machines

[pimlottc]

So basically, entropy bits do get used up, but it's not the problem you should worrying about.

[tptacek]

In the sense you're thinking about, entropy bits do not get "used up". The reason they're continuously refreshed is because something could theoretically happen to your system that compromises your CSPRNG internal state, and if the CSPRNG wasn't rekeyed you'd be permanently compromised.

[geofft]

If you ask a CSPRNG for 256 bits, it should return 256 bits chosen uniformly at random from 0 to 2^256-1.

If you ask it again for another 256 bits, it should return another 256 bits chosen uniformly at random from 0 to 2^256-1. That's pretty straightforward.

But you can satisfy both of these without the combined 512 bits being chosen uniformly at random from 0 to 2^512-1. For instance, if you generate a random 256-bit key for a 256-bit-block cipher, and encrypt 0 and 1 with the cipher, the two blocks are uniformly at random from their range, but they're not independent. Since there are only 2^256 possible keys, not all 2^512 outputs are possible by a straightforward counting argument.

You need quality entropy, but only up to the quantity of the security level of your system.

[bhickey]

> You need quality entropy, but only up to the quantity of the security level of your system.

What do you mean when you say entropy quality? As I said before, entropy is measured in bits. If you have two coin tosses that are correlated, you don't say "I've got 2-bits of low quality entropy". You simply have strictly less than 2-bits of entropy.