[erlang-questions] Multi-precision math, random number generator entropy, various other questions
Sun May 31 22:37:17 CEST 2009
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?
From: Dave Smith [mailto:]
Sent: Sunday, May 31, 2009 3:59 PM
To: Greg Perry
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 <> 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.
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
More information about the erlang-questions