A lot of confusion in this discussion thread and other promotions of this idea stems from the intuition that you can "run out" of entropy in your random number pool if you don't periodically replenish it with a physically unpredictable source. I have had this intuition too. Two things that feed it are the Linux random(4) man page and the behavior of GPG when generating a new private key.
tptacek tried to explain some of the problems in this intuition at https://sockpuppet.org/blog/2014/02/25/safely-generate-rando..., which relates to why he's so annoyed at some things people have said in this thread (and when discussing CSPRNG seeding in other places).
I like the idea of feeling physically unpredictable data into the CSPRNG, but for most purposes it's a misconception that doing so on an ongoing basis is in any way required by the design or that heavy users of randomness like CloudFlare would "run out of entropy" or "exhaust their entropy pool" if they didn't do so. The design of existing CSPRNGs would let CloudFlare use /dev/urandom for as long as it likes after securely seeding it just once, and there's no known cryptanalytic attack to which this practice would be vulnerable.
I've read that post now and previously (though not its references) and I feel that it never gets to the point where it explains how urandom can be equally safe as random.
Is the idea not that it is information-theoretically safe, but rather that the computational requirements are too great to figure out the state of the random-number generator even after a large amount of observed output?
Yes, it's partly about comparing the security model of CSPRNGs to the security model of ciphers (and I think some of the CSPRNG constructions are extremely closely related to popular ciphers and hash functions). Part of the argument is that a cipher can encrypt an extremely large amount of data under the same key, and in the same way a CSPRNG can create an extremely large amount of pseudorandom output from a small seed. In some cases, deriving the internal state of the CSPRNG from observed outputs should be as difficult as deriving the secret key of a cipher from observed ciphertext or from known plaintext/ciphertext pairs. Maybe tptacek can do another go-round on this topic and make this more explicit (because he certainly still gets frustrated about people's intuitions when it comes up).
There was something either in that piece or in another one by another crypto expert saying that if we don't believe that CSPRNGs have this security property, we shouldn't believe in the symmetric ciphers that we use them to generate key material for either, because they are constructed using the same kinds of techniques.
I also don't remember what Matthew Green disagreed with Thomas about here.
I guess this kind of, maybe, explains it, though in an oblique way, and even that only because I was already on the lookout for something about information-theoretical security vs. computational security.
It mostly brings up misconceptions I never had, and attacks those. For example, why would it matter that /dev/random gets its output from the same CSPRNG as /dev/urandom (or any other CSPRNG)? Shouldn't the output of the CSPRNG, assuming its state is large enough, contain as much entropy as its input?
The focus on giving me orders about what I should do, rather than telling me why, also gets old somewhere around the first time.
tptacek tried to explain some of the problems in this intuition at https://sockpuppet.org/blog/2014/02/25/safely-generate-rando..., which relates to why he's so annoyed at some things people have said in this thread (and when discussing CSPRNG seeding in other places).
I like the idea of feeling physically unpredictable data into the CSPRNG, but for most purposes it's a misconception that doing so on an ongoing basis is in any way required by the design or that heavy users of randomness like CloudFlare would "run out of entropy" or "exhaust their entropy pool" if they didn't do so. The design of existing CSPRNGs would let CloudFlare use /dev/urandom for as long as it likes after securely seeding it just once, and there's no known cryptanalytic attack to which this practice would be vulnerable.