4 ms·

Linux is one of the cases where the difference matters a lot, because /dev/random is blocking. I think it's BSD where the two devices are the same.

binarycrusader 11y ago
That doesn't match the repeated assertions of many posters here. I can only speak for Solaris knowledge-wise.
- ghshephard 11y ago
  "That doesn't match the repeated assertions of many posters here" - I'm curious, what doesn't match?
- keeperofdakeys 11y ago
  Here is a rough diagram which demonstrates it http://www.2uo.de/myths-about-urandom/structure-yes.png http://www.2uo.de/myths-about-urandom/structure-yes.png (from the detailed page http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/). /dev/random will block when the entropy estimate in low, but in a practical sense, the output of /dev/urandom and /dev/random are both random.
jakeogh 11y ago
Better to block than spit out low entropy data.
- oconnor663 11y ago
  That's true the way you say it, and that's definitely the problem that `getrandom()` solves by blocking if the random pool isn't initialized yet. But a lot of people take that to mean "you should never get more than N random bytes from a pool that has N bytes of entropy", and that part is wrong. All of crypto relies on being able to generate an arbitrary amount of good random bytes from a single 256-or-whatever-byte seed. Otherwise it wouldn't be safe to encrypt a long message with a short key.
tptacek 11y ago
The difference matters, but on Linux, the difference means that you need to avoid /dev/random, because the blocking behavior virtually never helps security but always reduces reliability.
- nickpsecurity 11y ago
  "because the blocking behavior virtually never helps security but always reduces reliability." I like how you put that. Best way to because infrastructure reliability is way too important to sacrifice over questionable security gains. Puts a QED on the whole discussion.
- binarycrusader 11y ago
  If your cryptography requirements require high entropy for the random numbers generated, then blocking is the right answer. In practice, that's rare, but some consumers have strict, hard requirements that can't be ignored.
  - Tomte 11y ago
    Once your CSPRNG has enough entropy in its internal state it has got this entropy. Retrieving output bytes doesn't change anything. The view "take three bytes output, lose three bytes entropy" is simply not correct.
- lomnakkus 11y ago
  Of course you probably already know this, but I think the root problem that OP is driving at here is that if you use /dev/urandom then you risk getting predictable values from /dev/urandom at startup[1], e.g. when initializing your server's SSH keys (or whatever). I seem to recall this being the root cause of thousands upon thousands of home routers being having weak keys. As such, it's important to point out. [1] That is, before enough external entropy has been gathered.
  - oconnor663 11y ago
    I think the new `getrandom` interface fixes that, by blocking until /dev/urandom is initialized.

binarycrusader 11y ago

That doesn't match the repeated assertions of many posters here. I can only speak for Solaris knowledge-wise.

ghshephard 11y ago
"That doesn't match the repeated assertions of many posters here" - I'm curious, what doesn't match?
keeperofdakeys 11y ago
Here is a rough diagram which demonstrates it http://www.2uo.de/myths-about-urandom/structure-yes.png http://www.2uo.de/myths-about-urandom/structure-yes.png (from the detailed page http://www.2uo.de/myths-about-urandom/ http://www.2uo.de/myths-about-urandom/). /dev/random will block when the entropy estimate in low, but in a practical sense, the output of /dev/urandom and /dev/random are both random.

jakeogh 11y ago

Better to block than spit out low entropy data.

oconnor663 11y ago
That's true the way you say it, and that's definitely the problem that `getrandom()` solves by blocking if the random pool isn't initialized yet. But a lot of people take that to mean "you should never get more than N random bytes from a pool that has N bytes of entropy", and that part is wrong. All of crypto relies on being able to generate an arbitrary amount of good random bytes from a single 256-or-whatever-byte seed. Otherwise it wouldn't be safe to encrypt a long message with a short key.

tptacek 11y ago

The difference matters, but on Linux, the difference means that you need to avoid /dev/random, because the blocking behavior virtually never helps security but always reduces reliability.

nickpsecurity 11y ago
"because the blocking behavior virtually never helps security but always reduces reliability." I like how you put that. Best way to because infrastructure reliability is way too important to sacrifice over questionable security gains. Puts a QED on the whole discussion.
binarycrusader 11y ago
If your cryptography requirements require high entropy for the random numbers generated, then blocking is the right answer. In practice, that's rare, but some consumers have strict, hard requirements that can't be ignored.
- Tomte 11y ago
  Once your CSPRNG has enough entropy in its internal state it has got this entropy. Retrieving output bytes doesn't change anything. The view "take three bytes output, lose three bytes entropy" is simply not correct.
lomnakkus 11y ago
Of course you probably already know this, but I think the root problem that OP is driving at here is that if you use /dev/urandom then you risk getting predictable values from /dev/urandom at startup[1], e.g. when initializing your server's SSH keys (or whatever). I seem to recall this being the root cause of thousands upon thousands of home routers being having weak keys. As such, it's important to point out. [1] That is, before enough external entropy has been gathered.
- oconnor663 11y ago
  I think the new `getrandom` interface fixes that, by blocking until /dev/urandom is initialized.