4 ms·

The advice of /dev/urandom vs. /dev/random is case-specific and doesn't apply to all operating systems. For Linux systems, in general, it would appear it doesn

The advice of /dev/urandom vs. /dev/random is case-specific and doesn't apply to all operating systems. For Linux systems, in general, it would appear it doesn't matter and /dev/urandom is sufficient. However, on systems such as Solaris, the cryptography group (whom I know personally) specifically recommends the use of /dev/random in some cases. Those cases are largely limited to specific cryptography requirements such as a hard requirement for high entropy sources. Regardless, all of this is largely moot at this point, as all *NIX-like systems (including Solaris) seem to be standardising on the getrandom() (in Linux first) and getentropy() (in OpenBSD first) which sidestep many of the more subtle, potential issues.

oconnor663 11y ago
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.
tptacek 11y ago
Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. In particular: the Solaris documentation suggests that urandom is fine for nonces, and /dev/random for long-term keys. But that's the opposite of the normal threat model for randomness! You care most about high-quality continuous-availability randomness for the nonces, where biases can be devastating to security, and attackers get repeated continual bites at the apple. If someone can explain the logic here, I'll update the page that AGL linked to in this article to account for that. I think the Solaris people are wrong. I'm not sure, but I'd be willing to bet a small amount of money on it.
- tedunangst 11y ago
  This is a very interesting point. An RNG that fixes the high bit of every word to zero still makes reasonably secure private keys, but start signing stuff with DSA and that RNG and you're screwed.
- binarycrusader 11y ago
  Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. I have, and again, most of the reasoning is Solaris-specific. The primary difference between urandom and random is currently higher quality re-keying for /dev/random, but there are a few internal implementation differences as well. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure". In addition, for Solaris /dev/random (and getrandom(GRND_RANDOM)) when the administrator explicitly configures a specific validation mode then the bits you get come from a validated DRBG (Deterministic Random Bit Generator). /dev/urandom is not affected by that validation mode. I think the Solaris people are wrong. I'm not sure, but I'd be willing to bet a small amount of money on it. They're really not in this case, but in fairness, you'd have no way of knowing about this without source code access and a few decades of knowledge about Solaris crypto. You can find a summary from two years ago written by one of the primary Solaris cryptography engineers and architects here: https://blogs.oracle.com/darren/en_GB/entry/solaris_random_number_generation https://blogs.oracle.com/darren/en_GB/entry/solaris_random_n... ...they intend to update it soon for the next Solaris release.
nickpsecurity 11y ago
"However, on systems such as Solaris, the cryptography group (whom I know personally) specifically recommends the use of /dev/random in some cases. Those cases are largely limited to specific cryptography requirements such as a hard requirement for high entropy sources." I'd also like to know what their specific arguments are on Solaris and for what use cases.

oconnor663 11y ago

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.

tptacek 11y ago

Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. In particular: the Solaris documentation suggests that urandom is fine for nonces, and /dev/random for long-term keys. But that's the opposite of the normal threat model for randomness! You care most about high-quality continuous-availability randomness for the nonces, where biases can be devastating to security, and attackers get repeated continual bites at the apple. If someone can explain the logic here, I'll update the page that AGL linked to in this article to account for that. I think the Solaris people are wrong. I'm not sure, but I'd be willing to bet a small amount of money on it.

tedunangst 11y ago
This is a very interesting point. An RNG that fixes the high bit of every word to zero still makes reasonably secure private keys, but start signing stuff with DSA and that RNG and you're screwed.
binarycrusader 11y ago
Can you personally ask the Solaris cryptography group why, in detail they think this is the case? No explanation I've seen for this makes sense. I have, and again, most of the reasoning is Solaris-specific. The primary difference between urandom and random is currently higher quality re-keying for /dev/random, but there are a few internal implementation differences as well. Fundamentally, it's about constraints placed on the implementation that currently make /dev/random more "secure". In addition, for Solaris /dev/random (and getrandom(GRND_RANDOM)) when the administrator explicitly configures a specific validation mode then the bits you get come from a validated DRBG (Deterministic Random Bit Generator). /dev/urandom is not affected by that validation mode. I think the Solaris people are wrong. I'm not sure, but I'd be willing to bet a small amount of money on it. They're really not in this case, but in fairness, you'd have no way of knowing about this without source code access and a few decades of knowledge about Solaris crypto. You can find a summary from two years ago written by one of the primary Solaris cryptography engineers and architects here: https://blogs.oracle.com/darren/en_GB/entry/solaris_random_number_generation https://blogs.oracle.com/darren/en_GB/entry/solaris_random_n... ...they intend to update it soon for the next Solaris release.

nickpsecurity 11y ago

"However, on systems such as Solaris, the cryptography group (whom I know personally) specifically recommends the use of /dev/random in some cases. Those cases are largely limited to specific cryptography requirements such as a hard requirement for high entropy sources." I'd also like to know what their specific arguments are on Solaris and for what use cases.