[Python-ideas] Should our default random number generator be secure?
Steven D'Aprano
steve at pearwood.info
Thu Sep 10 03:55:05 CEST 2015
On Wed, Sep 09, 2015 at 04:15:31PM -0700, Nathaniel Smith wrote:
> 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.
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, 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" :-)
I think Paul Moore's position is a good one. Anyone writing crypto code
without reading the docs and understanding what they are doing are
surely making more mistakes than just using the wrong PRNG. There may be
a good argument for adding arc4random support to the stdlib, but making
it the default (with the disadvantages discussed, breaking backwards
compatibility, surprising non-crypto users, etc.) won't fix the broken
crypto code. It will just give people a false sense of security and
encourage them to ignore the docs and write broken crypto code.
--
Steve
More information about the Python-ideas
mailing list