[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