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


More information about the Python-ideas mailing list