[Python-ideas] Should our default random number generator be secure?

[Nathaniel Smith]

[Sorry to Tim and Steven if they get multiple copies of this... Gmail
recently broke their Android app's handling of from addresses, so
resending, sigh]

On Sep 9, 2015 7:24 PM, "Tim Peters" <tim.peters at gmail.com> wrote:
[...]
> [Steven D'Aprano]
[...]
> > and for use with multiple threads, you can (and should) create your
> > own instances that don't share state. I call that "multi-thread
friendliness" :-)
>
> That's what people do, but MT's creators don't recommend it anymore
> (IIRC, their FAQ did recommend it some years ago).  Then they switched
> to recommending using jumpahead with a large value (to guarantee
> different instances' states would never overlap).  Now (well, last I
> saw) they recommend a parameterized scheme creating a distinct variant
> of MT per thread (not just different state, but a different (albeit
> related) algorithm):
>
>     http:// <http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf>
www.math.sci.hiroshima-u.ac.jp
<http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf>/~m-mat/MT/DC/
<http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf>dgene.pdf
<http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf>
>
> So I'd say it's clear as mud ;-)

Yeah, the independent-seed-for-each-thread approach is an option with any
RNG, but just like people feel better if they have a 100% certified
guarantee that the RNG output in a single thread will pass through every
combination of possible values (if you wait some cosmological time), they
also feel better if there is some 100% certified guarantee that the RNG
values in two threads will also be uncorrelated with each other.

With something like MT, if two threads did end up with nearby seeds, then
that would be bad: each thread individually would see values that looked
like high quality randomness, but if you compared across the two threads,
they would be identical modulo some lag. So all the nice theoretical
analysis of the single threaded stream falls apart.

However, for two independently seeded threads to end up anywhere near each
other in the MT state space requires that you have picked two numbers
between 0 and 2**19937 and gotten values that were "close". Assuming your
seeding procedure is functional at all, then this is not a thing that will
ever actually happen in this universe. So AFAICT the rise of explicitly
multi-threaded RNG designs is one of those fake problems that exists only
so people can write papers about solving it. (Maybe this is uncharitable.)

So there exist RNG designs that handle multi-threading explicitly, and it
shows up on feature comparison checklists. I don't think it should really
affect Python's decisions at all though.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150909/6b6023e9/attachment-0001.html>