[qrmn]

Honestly, this sales brochure of a "paper" tastes even worse than the BBC fluff piece. This is below the standard of paper I would have expected Black Hat to accept.

Good CSPRNG design is not a "dark art", and entropy is not "consumed" when a good CSPRNG is used. Any good CSPRNG uses a good PRF - any good block cipher in CTR mode, a hash, or a HMAC, perhaps - to stretch one good, solid, 256-bit entropy seed into as much cryptographically-secure random data as you'll ever need over the lifetime of your cryptosystem, and ratchets forward through the PRF after each call so the state cannot later be reversed (without breaking the PRF, but you're using a good one, so you'll be fine).

You need quality entropy to seed a CSPRNG - not quantity. Yes, it is, as we all know, very important you don't try to use a CSPRNG before its initial seed has collected enough good entropy - which is, yes, a particular problem in embedded systems or headless servers - but after that, the entropy in your CSPRNG seed isn't something that magically disappears, as you'll see from the design of Linux's newest random-number API, getrandom, patterned after the OpenBSD folks' ideas.

Reseeding a CSPRNG's state with more entropy is not a benefit, but in fact a potential risk every time you do it: it can result in entropy injection attacks if an attacker can observe the state, and control some of the entropy. That, in turn, could break your whole cryptosystem, especially if you're using fragile primitives like DSA or ECDSA. One source: http://blog.cr.yp.to/20140205-entropy.html

Detuned ring oscillator TRNGs [p2] can be troublesome to protect from RF side-channel attacks, or even RF injection attacks in pathological cases. Carefully used, they are fine, but best used when combined with shot-noise-based TRNGs. You can find those in surprising places: even the Raspberry Pi's BCM2835/BCM2836 has a perfectly serviceable one, available from /dev/hwrng after bcm2708-rng/bcm2835-rng has been loaded, and which rngd can use with no trouble.

Forgive me if, therefore, I perhaps wouldn't like to buy a "quantum random number generator" from Allied Minds Federal Innovations, Inc, who are behind this "paper", or to replace the OpenSSL RNG with theirs. That all feels far too much like a black box, and Dual_EC_DRBG is still fresh in our memory. I'd rather use the one Alyssa Rowan described to me on a napkin, thanks, or LibreSSL's/OpenBSD's arc4random with ChaCha20, or CTR_DRBG, or HMAC_DRBG.

[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.