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

[Dave Smith]

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.