2

This question already has an answer here:

I need to generate thousands of cryptographic keys. Can I just read the bits from /dev/urandom on a Red Hat system, or do I need to run it through a PRNG? My understanding is that /dev/urandom should be good enough, but I've had some push-back, so I'm ideally looking for solid academic references to say that /dev/urandom is good enough.

Note this paper: https://eprint.iacr.org/2013/338.pdf

marked as duplicate by Xander, forest, Neil Smithline, Tom K., Steffen Ullrich Apr 7 '18 at 13:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    Since you're looking for academic references this might be better suited to crypto.se – AndrolGenhald Apr 6 '18 at 21:02
  • 3
    under normal circumstances it's fine. – dandavis Apr 6 '18 at 21:02
3

/dev/urandom is a good choice, but the getrandom system call would be ideal, using the default flags.

As for references, this article is not strictly speaking academic but it's a reasonably easy read, and cites a number of experts in support of its explanations. I think this passage, which the article quotes from Daniel Bernstein, is well worth reproducing:

Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

  1. we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but
  2. we can figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test.

The article you've linked is more of a theoretical concern than a practical one. What it means isn't that the Linux RNG design is bad strictly speaking, but that it's not optimal in a number of regards, which however only apply in a very narrow scenario: when an attacker has managed to see the RNG's state at some point in its execution but (a) is no longer able to see the newer states and (b) is able to influence its entropy input. That's very specific—it lies at a very precise distance from normal operation (when the adversary hasn't seen the RNG state) and worst-case scenario (where the attacker has completely compromised the RNG and is able to see the state repeatedly).

  • Thanks. This is great, and I didn't know about getrandom, that's great. – vy32 Apr 7 '18 at 20:40
  • It turns out that getrandom is not available on Red Hat Enterprise Linux Server release 6.9 (Santiago). – vy32 Apr 9 '18 at 13:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.