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

Tim Peters tim.peters at gmail.com
Thu Sep 10 04:23:23 CEST 2015


[Nathaniel Smith]
>> The real reasons to prefer non-cryptographic RNGs are the auxiliary
>> features like determinism, speed, jumpahead, multi-thread
>> friendliness, etc. But the stdlib random module doesn't really provide
>> any of these (except determinism in strictly limited cases), so I'm
>> not sure it matters much.

[Steven D'Aprano]
> The default MT is certainly deterministic, and although only the output
> of random() itself is guaranteed to be reproducible, the other methods
> are *usually* stable in practice.
>
> There's a jumpahead method too,

Not in Python.  There was for the ancient Wichmann-Hill generator, but
not for MT.  A detailed sketch of ways to implement efficient
jumpahead for MT are given here:

    A Fast Jump Ahead Algorithm for Linear Recurrences
        in a Polynomial Space
    http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/jump-seta-lfsr.pdf

But because MT isn't a _simple_ recurrence, they're all depressingly
complex :-(  For Wichmann-Hill it was just a few integer modular
exponentiations.


> 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://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf

So I'd say it's clear as mud ;-)

> ...


More information about the Python-ideas mailing list