3 ms·

It's not outdated. Good quality PRNGs are not that new. But for good reasons, cryptographically sensitive applications do not want to be in a position of relyi

by B-Con 14y ago

It's not outdated. Good quality PRNGs are not that new. But for good reasons, cryptographically sensitive applications do not want to be in a position of relying purely on PRNG stretched output. Reading from urandom, you have no idea how much entropy was used to seed your output. Was it 5 bytes from last week, or 4K from 5 seconds ago? You don't know. The PRNG may be good enough to keep successive reads from being statistically correlated and such, but that is only one concern. Crypto, random number generation, and the practical implementations thereof is much more complicated than just the quality of the primitives. Sometimes you want to know for sure how much entropy is devoted to your read. In such a case, you use random.

marshray 14y ago
But for good reasons, cryptographically sensitive applications do not want to be in a position of relying purely on PRNG stretched output. What I'm saying is: if you are worried about the quality of your PRNG or the size of its pool or the secrecy of its content then you ought to choose a PRNG you can be confident in. Saying "I don't trust my PRNGs output for more than a short time" is equivalent to saying you believe your PRNG is defective (or you don't believe in one way functions in general). Was it 5 bytes from last week, or 4K from 5 seconds ago? You don't know. If your kernel takes a week to scavange 5 bytes unknown to an attacker, it's defective. You only need 100-200 bits, and the first seeding is the important one. This amount shouldn't take more than a few seconds to accumulate on all but the most quiet deterministic embedded systems. Sometimes you want to know for sure how much entropy is devoted to your read. Entropy is what the attacker doesn't know. The kernel can only try to estimate it based on wild-ass guesses about the properties of the attacker. Decrementing this estimate as RNG numbers are handed out is unjustifiable.

by B-Con 14y ago

marshray 14y ago

But for good reasons, cryptographically sensitive applications do not want to be in a position of relying purely on PRNG stretched output. What I'm saying is: if you are worried about the quality of your PRNG or the size of its pool or the secrecy of its content then you ought to choose a PRNG you can be confident in. Saying "I don't trust my PRNGs output for more than a short time" is equivalent to saying you believe your PRNG is defective (or you don't believe in one way functions in general). Was it 5 bytes from last week, or 4K from 5 seconds ago? You don't know. If your kernel takes a week to scavange 5 bytes unknown to an attacker, it's defective. You only need 100-200 bits, and the first seeding is the important one. This amount shouldn't take more than a few seconds to accumulate on all but the most quiet deterministic embedded systems. Sometimes you want to know for sure how much entropy is devoted to your read. Entropy is what the attacker doesn't know. The kernel can only try to estimate it based on wild-ass guesses about the properties of the attacker. Decrementing this estimate as RNG numbers are handed out is unjustifiable.