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

Greg Perry Greg.Perry@REDACTED
Sun May 31 19:02:18 CEST 2009


I have been experimenting with Erlang and have a few questions for the
development folks if possible.

For starters, it appears that Erlang supports arbitrary precision
integers for addition and multiplication, but not for division or any
other math operators.  For example, Comment #3 from this post dating
back to February 2008 mentions the problems with Erlang's bignum
libraries and as of R13B this has not yet been fixed:

Any idea on when, if at any time, Erlang will get robust bignum support
(including division, power operators etc)?

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?

For example, if I were to build a server in Erlang that implements
Diffie-Hellman encrypted listeners as separate spawned processes and I
then change the random seed, does that affect only the current running
process or is that a systemwide change?  If it's a systemwide change,
that has significant implications for overall system security (i.e. each
process would then have the same RNG seed variable and any subsequent
encryption key expiration and regeneration would then be drawn from the
same "shared" random seed).

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.



More information about the erlang-questions mailing list