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

[Per Hedeland]

>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:

The example uses math:pow/2, which is documented to return a float, and
so it does (incidentally it can also take floats as arguments, and as
also documented, the math module is just an interface to the
corresponding functions in the underlying C library/ies). How is this a
problem with the bignum implementation? There is (AFAIK) no bignum
version of pow/2 in the standard libraries, but you can write in 2-3
lines:

1> foo:ipow(2,55).
18014398509481984
2> foo:ipow(17,42).
4773695331839566234818968439734627784374274207965089

And where did you get the idea that division doesn't work for bignums?

3> v(2) div 17.
280805607755268602048174614102036928492604365174417
4> foo:ipow(17,41).
280805607755268602048174614102036928492604365174417

What other integer operations are you missing?

>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.

So you've already figured out that they are constants - does it matter
where the constants come from?

>  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?

And the answer is in the random(3) man page - actually there are two
answers. Or actually there are any number of answers, since nothing
forces you to use the random(3) module - e.g. some users prefer to use
the interface to the OpenSSL crypto library provided by the crypto(3)
module.

>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.

There is no "the Erlang TCP implementation". Various people have
implemented TCP in Erlang with various levels of success, mainly as a
learning experience and/or to see how well suited Erlang is for that
type of programming. Getting hold of good random numbers was probably
the least of their problems.

>  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.

The standard implementation of Erlang is a user level process running on
top of an OS that these days almost always has a quality implementation
of entropy gathering - any attempt to re-implement that in the Erlang
runtime is guaranteed to result in something with inferior quality.

--Per Hedeland