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

random832 at fastmail.us random832 at fastmail.us
Fri Sep 11 23:12:00 CEST 2015


On Wed, Sep 9, 2015, at 17:02, Nathaniel Smith wrote:
> Keeping that promise in mind, an alternative would be to keep both
> generators around, use the cryptographically secure one by default, and
> switch to MT when someone calls
> 
>   seed(1234, generator="INSECURE LEGACY MT")
> 
> But this would justifiably get us crucified by the security community,
> because the above call would flip the insecure switch for your entire
> program, including possibly other modules that were depending on random
> to
> provide secure bits.

I just realized, OpenBSD has precisely this functionality, for the
rand/random/rand48 functions, in the "_deterministic" versions of their
respective seed functions. So that's probably not a terrible path to go
down:

Make a Random class that uses a CSPRNG and/or os.urandom until/unless it
is explicitly seeded. Use that class for the global instance. We could
probably skip the "make a separate function name to show you really mean
it" because unlike C, Python has never encouraged explicitly seeding
with the {time, pid, four bytes from /dev/random} when one doesn't
actually want determinism. (The default seed in C for rand/random is
*1*; for rand48 it is an implementation-defined, but specified to be
constant, value).

For completeness, have getstate return a tuple of a boolean (for which
mode it is in) and whatever state Random returns. setstate can accept
either this tuple, or for compatibility whatever Random uses.


More information about the Python-ideas mailing list