3 ms·

Not sure what you mean, but /dev/random should indeed be a blocking read. The question is whether they should be using /dev/random to begin with.

by B-Con 14y ago

marshray 14y ago
Linux /dev/random is based on an old design based on obsolete recommendataions. A modern cryptographically-secure properly implemented RNG doesn't need to worry about enropy exhaustion after a good initial seeding. On the contrary, there have been real security problems seen when apps unpredictably get nothing back from the RNG. Exhaustion can also be provoked by a remote attacker.
- andrewcooke 14y ago
  how does that contradict the person you're replying to? surely it would be a non-blocking read that would return empty. you seem to be saying that apps generally should need /dev/random only rarely. which seems sensible, but is also what the post one up suggested. in short you seem to be in confused and annoyed agreement. [vaguely related interesting post on urandom quality - http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939 http://security.stackexchange.com/questions/3936/is-a-rand-f...]
  - marshray 14y ago
    I'm saying that regardless of whether /dev/random is read with a blocking call, it shouldn't ever block. (Except during initial seeding right at startup). +1 on the linked post.
- 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.

Not sure what you mean, but /dev/random should indeed be a blocking read. The question is whether they should be using /dev/random to begin with.

by B-Con 14y ago

Not sure what you mean, but /dev/random should indeed be a blocking read. The question is whether they should be using /dev/random to begin with.

marshray 14y ago

Linux /dev/random is based on an old design based on obsolete recommendataions. A modern cryptographically-secure properly implemented RNG doesn't need to worry about enropy exhaustion after a good initial seeding. On the contrary, there have been real security problems seen when apps unpredictably get nothing back from the RNG. Exhaustion can also be provoked by a remote attacker.

andrewcooke 14y ago
how does that contradict the person you're replying to? surely it would be a non-blocking read that would return empty. you seem to be saying that apps generally should need /dev/random only rarely. which seems sensible, but is also what the post one up suggested. in short you seem to be in confused and annoyed agreement. [vaguely related interesting post on urandom quality - http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939 http://security.stackexchange.com/questions/3936/is-a-rand-f...]
- marshray 14y ago
  I'm saying that regardless of whether /dev/random is read with a blocking call, it shouldn't ever block. (Except during initial seeding right at startup). +1 on the linked post.
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.