I've given up on the hope that these myths will ever die. Every time it's relevant, someone pipes up complaining urandom isn't safe for use, or will run out of entropy. Have a look at the bugs for Node, Ruby and Wordpress.<p>And inevitably, the appeal to authority ends up referring to these projects.<p>Serious question, if I submitted a patch for the man page detailing the content of this myths page, is there a chance it might go somewhere and put somewhat of an end to some of this?
A useful article, originally from 2014 but updated recently.<p>Previous HN discussions:<p><a href="https://news.ycombinator.com/item?id=7359992" rel="nofollow">https://news.ycombinator.com/item?id=7359992</a><p><a href="https://news.ycombinator.com/item?id=10149019" rel="nofollow">https://news.ycombinator.com/item?id=10149019</a>
While it may be generally better to use /dev/urandom, what about the Mining Your Ps and Qs paper?[1]. It finds that:<p>> Every software package we examined relies on /dev/urandom to generate cryptographic keys; however, we find that Linux’s random number generator (RNG) can exhibit a boot-time entropy hole that causes urandom to produce deterministic output under conditions likely to occur in headless and embedded devices. In experiments with OpenSSL and Dropbear SSH, we show how repeated output from the system RNG can lead not only to repeated long-term keys but also to factorable RSA keys and repeated DSA ephemeral keys due to the behavior of application-specific entropy pools.<p>This is mentioned a little at the end of the article. Would it be a breaking change for Linux to block urandom at startup?<p>[1] <a href="https://factorable.net/weakkeys12.conference.pdf" rel="nofollow">https://factorable.net/weakkeys12.conference.pdf</a>
/dev/urandom does have a problem with not enough entropy sometimes. Yes it never "runs out" of entropy when it has enough previously. But when a computer first boots up, sometimes it doesn't have enough entropy yet, and gives bad output.<p>This causes problems in practice, allowing people to crack RSA private keys.
<a href="https://factorable.net/weakkeys12.extended.pdf" rel="nofollow">https://factorable.net/weakkeys12.extended.pdf</a>
tldr; just use /dev/urandom --- this should be at the top of the page.<p>Maybe prefix the bold sections with Myth: so it is easier to read. I was really confused as to which side of the argument the author was on at first...
Also Filippo Varsaldo has a nice talk about this:<p><a href="https://www.youtube.com/watch?v=Q8JAlZ-HJQI" rel="nofollow">https://www.youtube.com/watch?v=Q8JAlZ-HJQI</a>
So what are the cases when you should <i>actually</i> use /dev/random and not /dev/urandom? The article fails to address this in clear.
I am so confused about this all the time. My solution is to go see what Go is using: <a href="https://golang.org/src/crypto/rand/rand.go" rel="nofollow">https://golang.org/src/crypto/rand/rand.go</a>
Trusting them to do the Right Thing.<p>Is there a good reason why /dev/random AND /dev/urandom exist?
I bought a TrueRNG v3 [0] a month or so ago and have been using it with rngd / rng-tools.<p>I wish rngd was easier to use with multiple entropy sources, however. Even w/ RDRAND (times two -- dual CPUs), a TPM, and the TrueRNG, it's difficult to (easily) tell which of these are being used and/or if more than one is being used.<p>Ideally, I'd like to be able to tell rngd to use/mix the TrueRNG, RDRAND in both CPUs, the TPM, and any other entropy sources I may come up with, such as RTL-SDRs doing funky things [1]. I suppose I could just run multiple instances of rngd, though.<p>Anyway, I've switched to just using /dev/random for pretty much everything (where it can be configured) since, with the TrueRNG, it never blocks on me now.<p>[0]: <a href="http://ubld.it/truerng_v3" rel="nofollow">http://ubld.it/truerng_v3</a><p>[1]: <a href="https://www.google.com/search?q=rtl-str+entropy" rel="nofollow">https://www.google.com/search?q=rtl-str+entropy</a>
What I've got from this thread is that you never touch security-related prngs unless you're an expert in security, cryptography and operating systems, <i>all at the same time</i>, and even then you care a lot. Thanks for deeper debunking.
The advice on this page is accurate and in line with what cryptography experts will recommend.<p>That said, if you're looking for more of the <i>how</i> and less of the <i>why</i>: <a href="https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages" rel="nofollow">https://paragonie.com/blog/2016/05/how-generate-secure-rando...</a><p>Contains snippets and recommendations for C/C++, Erlang, Go, Java, (Browser) JavaScript, .NET, Node.js, PHP, Python, Ruby, and Rust.
This is really no problem now that Intel chips ship with RDRAND instructions. Linux should follow BSD/Mac's footsteps and incorporate a good CSPRNG non-blocking devices (after seed). I believe BSD is moving towards Fortuna, which is perfect for this use-case.<p>With these instructions you'll always get a "good"[1] seed for your CSPRNG, and that includes virtual machines and clones.<p>[1] Of course that depends on how much you trust Intel. Don't ask the crypto mailing lists whether this is a good idea :-)
One to add - it's not fast at providing a value<p>I remember learning this when I found /dev/urandom multiple times slower than /dev/null while writing garbage data to disk.
"And even if you need that peace of mind, let me tell you a secret: no practical attacks on AES, SHA-3 or other solid ciphers and hashes are known in the “unclassified” literature, either. Are you going to stop using those, as well? Of course not!"<p><a href="http://www.pcworld.com/article/3117728/security/why-quantum-computing-has-the-cybersecurity-world-white-knuckled.html" rel="nofollow">http://www.pcworld.com/article/3117728/security/why-quantum-...</a><p><a href="https://en.wikipedia.org/wiki/Grover's_algorithm" rel="nofollow">https://en.wikipedia.org/wiki/Grover's_algorithm</a>