No! That's not how /dev/random works. You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator. /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator; that is the difference between it and urandom.
> You aren't literally reading raw entropy from /dev/random. You're reading the ouput of a keystream generator.
Yes, I understand. It's the same one that /dev/urandom reads out of, if I am not mistaken.
> /dev/random has bolted onto it an "entropy estimator" that tries to match the draw from the generator to the inputs to the generator
Right, and it blocks if it estimates that there is little or no entropy left. So doesn't that mean that approximately (i.e. subject to the quality of the estimation) 100% of the time there is no entropy left, it will block?
Maybe I should point out that I am a complete novice with regard to this stuff, and I am just trying to understand where my misunderstanding lies. So, my apologies for using imprecise terminology.
Now, I understand that entropy doesn't "run out" on a PRNG in the sense that it can "run out" with an entropy pool. However my understanding is that the purpose of /dev/random is to behave "like an entropy pool" in that the continual reseeding reduces its vulnerability to RNG attacks. So when I say that that the PRNG has "run out" of entropy, I mean that it is behaving more like a PRNG than an entropy pool due to a lack of reseeding.
Is this a valid concern or not? I have seen mixed answers in this thread.
* Continual reseeding happens to both /dev/random and urandom
* Continual reseeding does not improve resistance to cryptanalytic attacks on the RNG itself
* Continual reseeding does provide a degree of forward secrecy; if your box gets owned up and you lose the RNG state to an adversary, you eventually recover from it
* Blocking based on "entropy estimators" is an incoherent response to any risk that the kernel RNG faces; it has no relationship to any actual policy about forward secrecy
* The blocking /dev/random does is based on a misunderstanding its developer has about how CSPRNGs provide security.
You are seeing mixed answers because 'saurik doesn't like the tone of the "just use urandom" articles. He thinks it glosses over the issue of first-ever-boot cold-start-entropy. I disagree strongly that you need to care about that issue, ever. But he and I probably do agree about every bullet in this comment.
