[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