[Python-ideas] PEP 504: Using the system RNG by default
ncoghlan at gmail.com
Wed Sep 16 18:05:53 CEST 2015
On 17 September 2015 at 01:54, Steven D'Aprano <steve at pearwood.info> wrote:
> I propose:
> - The random module's API is left as-is, including the default PRNG.
> Backwards compatibility is important, code-churn is bad, and there are
> good use-cases for a non-CSPRNG.
> - We add at least one CSPRNG. I leave it to the crypto-wonks to decide
> - We add a new module, which I'm calling "secrets" (for lack of a better
> name) to hold best-practice security-related functions. To start with,
> it would have at least these three functions: one battery, and two
> building blocks:
> + secrets.token to create password recovery tokens or similar;
> + secrets.random calls the CSPRNG; it just returns a random number
> (integer?). There is no API for getting or setting the state,
> setting the seed, or returning values from non-uniform
> + secrets.choice similarly uses the CSPRNG.
> Developers will still have to make a choice: "do I use secrets, or
> random?" If they're looking for a random token (or password?), the
> answer is obvious: use secrets, because the battery is already there.
> For reasons that I will go into below, I don't think that requiring this
> choice is a bad thing. I think it is a *good* thing.
> secrets becomes the go-to module for things you want to keep secret.
> random remains the module you use for games and simulations.
> If there is interest in this proposed secrets module, I'll write up a
> proto-PEP over the weekend, and start a new thread for the benefit of
> those who have muted this one.
Oh, *this* I like (minus the idea of introducing a CSPRNG -
random.SystemRandom will be a good choice for this task).
"Is it an important secret?" is a question anyone can answer, so
simply changing the proposed name addresses all my concerns regarding
having to ask people to learn how to answer a difficult question that
isn't directly related to what they're trying to do.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas