Important excerpt from random.c:<p><pre><code> * When random bytes are desired, they are obtained by taking the SHA
* hash of the contents of the "entropy pool". The SHA hash avoids
* exposing the internal state of the entropy pool. It is believed to
* be computationally infeasible to derive any useful information
* about the input of SHA from its output. Even if it is possible to
* analyze SHA in some clever way, as long as the amount of data
* returned from the generator is less than the inherent entropy in
* the pool, the output data is totally unpredictable. For this
* reason, the routine decreases its internal estimate of how many
* bits of "true randomness" are contained in the entropy pool as it
* outputs random numbers.
*
* If this estimate goes to zero, the routine can still generate
* random numbers; however, an attacker may (at least in theory) be
* able to infer the future output of the generator from prior
* outputs. This requires successful cryptanalysis of SHA, which is
* not believed to be feasible, but there is a remote possibility.
* Nonetheless, these numbers should be useful for the vast majority
* of purposes.
</code></pre>
This is the same old story. /dev/urandom is what you should use, unless you believe that the hash function is broken
This is sort of accidentally technically correct.<p>It's not <i>always</i> right to use /dev/urandom on Linux. During system startup, it does bad things if the entropy pool hasn't been initialized yet. So yeah. You shouldn't <i>always</i> use /dev/urandom, if you are writing code that's designed to run during system startup.<p>In every other case, you should use /dev/urandom.<p>It's a super-minor technicality preventing this article from being 100% wrong. Please don't follow its advice.
For an alternative (and more widely accepted afaict) opinion, see <a href="http://www.2uo.de/myths-about-urandom/" rel="nofollow">http://www.2uo.de/myths-about-urandom/</a>
<p><pre><code> Majority of web pages and blog posts I’ve read suggests to use /dev/urandom
</code></pre>
Even the man page was updated to state that this is what you want unless under specific circumstances:<p><pre><code> The /dev/random interface is considered a legacy interface, and
/dev/urandom is preferred and sufficient in all use cases, with the
exception of applications which require randomness during early boot
time; for these applications, getrandom(2) must be used instead,
because it will block until the entropy pool is initialized.</code></pre>
Or one could just use the syscall[0] which does the right thing™. If no flags are provided it only blocks at boot until the pool is properly seeded and then becomes nonblocking until shutdown.<p>[0] <a href="http://man7.org/linux/man-pages/man2/getrandom.2.html" rel="nofollow">http://man7.org/linux/man-pages/man2/getrandom.2.html</a>
The post lacks the term "CSPRNG", which I would have thought to be there in a discussion about randomness. Especially in collaboration with the concept of security.<p>The long story short, a Pseudorandom sequence can be more than enough in a security setting, provided that the stream of bits follow certain rules. For instance, it should be impossible to guess the next bit based on known history of bits. If /dev/urandom is backed by such a generator, which it is in many modern operating systems, then it is arguably safer than what the claim of the post is.