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

[Nick Coghlan]

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
>   which.
>
> - 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
>     distributions;
>
>   + 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia