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

[Greg Perry]

Dave,

Thank you for the prompt response, the seed information you provided is very helpful.

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?

Regards

Greg

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

On Sun, May 31, 2009 at 11:02 AM, Greg Perry <Greg.Perry@REDACTED> wrote:
> Second question is the entropy pool used for the Erlang random module.
> Where are the three initial seeds drawn from and how does this change 
> with compiled Erlang vs. the interpreter?  Stopping and restarting the 
> interpreter always yields the same random seeds, which in turn 
> generates the same sequence of random integers from the random module.  
> The billion dollar question is this:  when spawning new processes, 
> does changing the random seed result in a systemwide change of the 
> random seed (affecting all processes), or does changing the seed only 
> affect the scope of a single process?

The random module (part of stdlib app) stores the current seed in the current process dictionary -- changing the seed ONLY affects the current process. When using the random module I typically seed the RNG when the process starts up with the current time (erlang:now/0). This ensures each process gets a different seed since the now/0 function is monotonically increasing. Obviously, if you're starting up many processes simultaneously they will have very similar seeds and the first few numbers will probably be close -- but in a very short amount of time the RNG kicks in and everything diverges nicely.

Please note, I don't believe the random module is suitable for _any_ cryptographic usage. If you want a strong RNG, you will want to look at crypto:rand_bytes/1.  That module uses the OpenSSL RNG which should be fine for cryptographic purposes.

> As it stands right now I don't see how any robust TCP-based 
> communications framework can be built upon Erlang, at least not within 
> the 31-bit RNG requirement of the TCP RFC for reliable and secure 
> TCP-based intercommunications.  Given the current lack of RNG quality 
> with Erlang (and if the Erlang TCP implementation is using that same 
> RNG for initial sequence number generation) then all ISNs would be 
> easily predictable and thus easily subverted and compromised.  This 
> goes without mentioning the problems with developing any type of 
> encryption framework eith Erlang without also building at the very 
> least a separate entropy gathering process, a robust entropy pool, and RNG library.

I'm not precisely sure what you mean by line of reasoning -- the Erlang VM uses the default TCP stack available from the O/S, so it is the responsibility of the O/S to ensure TCP sequence numbers are assigned with sufficient randomness.

Given your interest in the inner workings, it might be worth reviewing the code in stdlib/src/random.erl and crypto/c_src/cryto_drv.c.

D.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.46/2143 - Release Date: 05/31/09 05:53:00