[Python-ideas] PEP 504: Using the system RNG by default
njs at pobox.com
Wed Sep 16 06:09:49 CEST 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas