
Randomness in GNU/Linux - enyone
http://juho.tykkala.fi/Randomness-in-Linux
======
tixzdk
Important excerpt from random.c:

    
    
       * 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.
    

This is the same old story. /dev/urandom is what you should use, unless you
believe that the hash function is broken

~~~
pcwalton
> /dev/urandom is what you should use, unless you believe that the hash
> function is broken

And if you believe the hash function is broken, then the crypto you're using
that random number generation for is probably broken too.

------
chowells
This is sort of accidentally technically correct.

It's not _always_ 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 _always_ use /dev/urandom, if you are writing code that's
designed to run during system startup.

In every other case, you should use /dev/urandom.

It's a super-minor technicality preventing this article from being 100% wrong.
Please don't follow its advice.

~~~
notfed
Point noted. And the fact that this blog doesn't point this out makes it OH so
wrong.

Granted, many modern OS's retain entropy across reboots, eliminating even this
problem.

------
Shoop
For an alternative (and more widely accepted afaict) opinion, see
[http://www.2uo.de/myths-about-urandom/](http://www.2uo.de/myths-about-
urandom/)

------
Rafert

      Majority of web pages and blog posts I’ve read suggests to use /dev/urandom
    

Even the man page was updated to state that this is what you want unless under
specific circumstances:

    
    
      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.

------
notfed
Yet another blogger spreading an ancient myth.

"/dev/urandom gives lower quality randomness" \- Simply. Not. True.

------
the8472
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.

[0] [http://man7.org/linux/man-
pages/man2/getrandom.2.html](http://man7.org/linux/man-
pages/man2/getrandom.2.html)

------
jlouis
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.

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.

------
GFK_of_xmaspast
Why's it GNU/Linux when there's no userspace involved?

