[Python-ideas] Python's Source of Randomness and the random.py module Redux

Donald Stufft donald at stufft.io
Thu Sep 10 03:30:16 CEST 2015

On September 9, 2015 at 8:01:17 PM, Donald Stufft (donald at stufft.io) wrote:
> It seems to boil down to, do we want to try to protect users by default or at
> least make it more obvious in the API which one they want to use (I think yes),
> and if so do we think that /dev/urandom is "fast enough" for most people in
> group #3 and if not, do we agree with Theo that a modern userland CSPRNG is
> safe enough to use, or do we agree with Thomas that it's not and if we think
> that it is, do we use arc4random and what do we do on systems that don't have
> a modern userland CSPRNG in their libc.

Ok, I've talked to an honest to god cryptographer as well as some other smart

Here's the general gist:

Using a userland CSPRNG like arc4random is not advisable for things that you
absolutely need cryptographic security for (this is group #2 from my original
email). These people should use os.urandom or random.SystemRandom as they
should be doing now. In addition os.urandom or random.SystemRandom is
probably fast enough for most use cases of the random.py module, however it is
true that using os.urandom/random.SystemRandom would be slower than MT. It is
reasonable to use a userland CSPRNG as a "default" source of randomness or in
cases where people care about speed but maybe not about security and don't
need determinism.

However, they've said that the primary benefit in using a userland CSPRNG for
a faster cryptographically secure source of randomness is if we can make it the 
default source of randomness for a "probably safe depending on your app" safety
net for people who didn't read or understand the documentation. This would make
most uses of random.random and friends secure but not deterministic.

If we're unwilling to change the default, but we are willing to deprecate the
module scoped functions and force users to make a choice between
random.SystemRandom and random.DeterministicRandom then there is unlikely to
be much benefit to also adding a userland CSPRNG into the mix since there's no
class of people who are using an ambiguous "random" that we don't know if they
need it to be secure or deterministic/fast.

So I guess my suggestion would be, let's deprecate the module scope functions
and rename random.Random to random.DeterministicRandom. This absolves us of
needing to change the behavior of people's existing code (besides deprecating
it) and we don't need to decide if a userland CSPRNG is safe or not while still
moving us to a situation that is far more likely to have users doing the right

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Python-ideas mailing list