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