Performance of /dev/urandom and /dev/random

[DG]

On Thu, Sep 27, 2012 at 5:09 PM, Mihir Pandya <mihir.m.pandya at gmail.com> wrote:
> Hey guys,
>
> I'm interested to know why generating cryptographically secure random
> numbers takes so long, particularly in my case. I have two Java classes that
> are generating a million random numbers. One is generating random numbers
> regularly while the other is using SecureRandom to generate the numbers. The
> SecureRandom method is taking almost double the time and I realised that
> it's because the method reads from /dev/urandom (not sure which) and obtains
> its random numbers from the entropy pool there.
>
> I wanted to know where I can read about the exact mechanism used to generate
> the cryptographically secure random numbers through SecureRandom and if
> there is any way to make it faster.
>
> --
> Mihir Pandya
>

>From 'man urandom'

      When read, the /dev/random device will only return random bytes
within the estimated number of bits of noise in the entropy pool.
/dev/random should be suitable for uses
       that need very high quality randomness such as one-time pad or
key generation.  When the entropy pool is empty, reads from
/dev/random will block until  additional  envi‐
       ronmental noise is gathered.

       A read from the /dev/urandom device will not block waiting for
more entropy.  As a result, if there is not sufficient entropy in the
entropy pool, the returned values are
       theoretically vulnerable to a cryptographic attack on the
algorithms used by the driver.  Knowledge of how to do this is not
available in the current unclassified litera‐
       ture, but it is theoretically possible that such an attack may
exist.  If this is a concern in your application, use /dev/random
instead.

Now I *believe* the entropy pool is filled by IO events - network
activity, disk access, keyboard pounding, etc...  I'm sure there is
more documentation somewhere online as to the specifics.

Hope that helps,
Danny G