[erlang-questions] Multi-precision math, random number generator entropy, various other questions

[Greg Perry]

For the test application I am developing it's somewhat of a performance to quality tradeoff.  Any ideas what the performance differences would be between random:uniform() and crypto:rand_uniform()?

The entropy of /dev/urandom would be sufficient for what I am building but that's assuming there are no I/O blocking issues with a large number of Erlang processes talking to /dev/urandom at the same time.

I have a phase space entropy analysis tool that I developed some time ago in Python, if I can dig it up I will do some visualization plots of the internal random:uniform() module and the OpenSSL crypto:rand_uniform() module to see what the differences are between the two and what level of discernable patterns emerge from both.

-----Original Message-----
From: Dave Smith [mailto:dizzyd@REDACTED] 
Sent: Sunday, May 31, 2009 4:45 PM
To: Greg Perry
Subject: Re: [erlang-questions] Multi-precision math, random number generator entropy, various other questions

On Sun, May 31, 2009 at 2:37 PM, Greg Perry <Greg.Perry@REDACTED> wrote:

> I have been looking at deriving seed values from /dev/urandom but obviously that will only work with platforms that support such a device.  Given the non-blocking nature of /dev/urandom, would there be any issues with simultaneous reads from /dev/urandom at the filesystem level I wonder?  ie would there be performance benefits to developing an entropy gathering module and internalizing the initial seed and/or random number generation process, or can /dev/urandom be accessed simultaneously by at least the default 32,768 default process limit of Erlang without a performance penalty by reading /dev/urandom from the host filesystem?

I am not a crypto expert, but it seems to me that just choosing a strong random seed value is insufficient -- the heart of the problem is that the RNG algorithm is simply not designed to generate cryptographically strong random numbers. If you want strong random number generation use the crypto module -- it pulls from /dev/urandom and various other entropy sources via OpenSSL.

D.