[Python-ideas] PEP 504: Using the system RNG by default

Guido van Rossum guido at python.org
Wed Sep 16 06:15:22 CEST 2015

Clearly I need to mute this thread too. :-(

On Tue, Sep 15, 2015 at 9:09 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Sep 15, 2015 1:19 PM, "Guido van Rossum" <guido at python.org> wrote:
> >
> > How about the following. We add a fast secure random generator to the
> stdlib as an option, and when it has proven its worth a few releases from
> now we consider again whether the default random() can be made secure
> without breaking anything.
> If we have a fast secure RNG, then the standard Random object might as
> well at least use it by default until someone actually sets or reads the
> state (and then switch to MT at that point). Until one of these events
> happens, the two RNGs are indistinguishable, and this would be a 100%
> backwards compatible change. (It might even make sense to backport to 2.7.)
> The limitation is that if library A uses the global random object without
> seeding in a security sensitive context, and library B uses seeding, then a
> program that just uses library A will be secure, but if it then starts
> using library B it will become insecure. But this is still better than the
> current situation where library A is always insecure.
> The only case where this would actually have a downside compared to status
> quo (assuming arc4random lives up to it's reputation for speed etc) is if
> people start assuming that the default random object is in fact secure and
> intentionally choosing to use it in security sensitive situations. But
> hopefully people who know enough to realize that this is a decision they
> need to make will also read the docs where it clearly states that this is
> only a best-effort kind of hardening mechanism and that using
> random.Random/the global methods for cryptographic purposes is still a bug.
> -n

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/f0668cf9/attachment.html>

More information about the Python-ideas mailing list