On Fri, Sep 28, 2012 at 5:14 AM, DG <dangets@gmail.com> wrote:

On Thu, Sep 27, 2012 at 5:09 PM, Mihir Pandya <mihir.m.pandya@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

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

The entropy pool is filled by IO events as mentioned previously. The random data is taken from various devices connected to the system. /dev/urandom uses the device's randomness. So urandom will take more time than /dev/random. Hope this helps, Prasanna Kumar T S M

Thanks, that helped.

From what I've read so far, the capacity of my entropy pool is 4096 bytes and it's current size is 155 bytes. I'm wondering if the size of the entropy pool affects the speed of generating the random numbers because instead of breaking when the entropy pool runs out of bytes, urandom will read the entropy pool again and generate more random numbers. So a smaller pool size would mean that the frequency of file re-reads is higher which would make it slower?

If I wanna test this hypothesis, is there any convenient way for me to manually alter the size of the entropy pool size? I'm really trying to optimize the generation of the cyrptographically secure random numbers. On Fri, Sep 28, 2012 at 6:09 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote:

Hi...

On Fri, Sep 28, 2012 at 3:54 PM, Sannu K <sannumail4foss@gmail.com> wrote:

...

So urandom will take more time than /dev/random.

it's the other way around....

-- regards,

Mulyadi Santosa Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com

-- Mihir Pandya