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

[Tim Peters]

{Guido]
> ...
> The two core Python experts on the random module
> have given me opinions suggesting that there's not
> much wrong with MT, so here I am.

There is nothing _right_ about MT in a crypto context - it's entirely
unsuitable for any such purpose, and always was.  Just to be clear
about that ;-)  But it's an excellent generator for almost all other
purposes.

So the real question is:  whose use cases do you want to cater to by default?

If you answer "crytpo", then realize the Python generator will have to
change every time the crypto community changes its mind about what's
_currently_ "good enough".  There's a long history of that already.

Indeed, there are already numerous "chacha" variants.  For a brief
overview, scroll down to the ChaCha20 section of this exceptionally
readable page listing pros and cons of various generators:

    http://www.pcg-random.org/other-rngs.html

There are no answers to vital pragmatic questions (like "is it
possible to supply a seed to get reproducible results?") without
specifying whose implementation of which chacha variant you're asking
about.

I've always thought Python should be a follower rather than a leader
in this specific area.  For example, I didn't push for the Twister
before it was well on its way to becoming a de facto standard.

Anyway, it's all moot until someone supplies a patch - and that sure
ain't gonna be me ;-)


On Wed, Sep 9, 2015 at 11:35 AM, Guido van Rossum <guido at python.org> wrote:
> I've received several long emails from Theo de Raadt (OpenBSD founder) about
> Python's default random number generator. This is the random module, and it
> defaults to a Mersenne Twister (MT) seeded by 2500 bytes of entropy taken
> from os.urandom().
>
> Theo's worry is that while the starting seed is fine, MT is not good when
> random numbers are used for crypto and other security purposes. I've
> countered that it's not meant for that (you should use random.SystemRandom()
> or os.urandom() for that) but he counters that people don't necessarily know
> that and are using the default random.random() setup for security purposes
> without realizing how wrong that is.
>
> There is already a warning in the docs for the random module that it's not
> suitable for security, but -- as the meme goes -- nobody reads the docs.
>
> Theo then went into technicalities that went straight over my head,
> concluding with a strongly worded recommendation of the OpenBSD version of
> arc4random() (which IIUC is based on something called "chacha", not on "RC4"
> despite that being in the name). He says it is very fast (but I don't know
> what that means).
>
> I've invited Theo to join this list but he's too busy. The two core Python
> experts on the random module have given me opinions suggesting that there's
> not much wrong with MT, so here I am. Who is right? What should we do? Is
> there anything we need to do?
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/