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

[Guido van Rossum]

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.

On Tue, Sep 15, 2015 at 12:43 PM, David Mertz <mertz at gnosis.cx> wrote:

> I commonly use random.some_distribution() as a quick source of
> "randomness" knowing full well that it's not cryptographic. Moreover, I
> usually do so initially without setting a seed.
>
> The first question I want to answer is "does this random process behave
> roughly as I expect?" But in the back of my mind is always the thought,
> "If/when I want to reuse this I'll add a seed for reproducibility". It
> would never occur to me to reach for the random module if I want to do
> cryptography.
>
> It's a good and well established API that currently exists. Sure, add a
> submodule random.crypto (or whatever name), but I'm -1 on changing anything
> whatsoever on the module functions that are well known.
> On Sep 15, 2015 11:26 AM, "Random832" <random832 at fastmail.com> wrote:
>
>> On Tue, Sep 15, 2015, at 13:33, Guido van Rossum wrote:
>> > I don’t want to change this API and I don’t want to introduce
>> deprecation
>> > warnings – the API is fine, and the warnings will be as ineffective as
>> > the
>> > warnings in the documentation.
>>
>> The output of random.random today when it's not seeded / seeded with
>> None isn't _really_ deterministic - you can't reproduce it, after all,
>> without modifying the code (though in principle you could do
>> seed(None)/getstate the first time and then setstate on subsequent
>> executions - it may be worth supporting this use case?) - so changing it
>> isn't likely to affect anyone - anyone needing MT is likely to also be
>> using the seed functions.
>>
>> >   random.set_random_generator(<instance>)
>>
>> What do you think of having calls to seed/setstate(/getstate?)
>> implicitly switch (by whatever mechanism) to MT? This could be done
>> without a deprecation warning, and would allow existing code that relies
>> on reproducible values to continue working without modification?
>>
>> [indirection in global functions]...
>> > (and similar for all related functions).
>>
>> global getstate/setstate should also save/replace the _inst or its type;
>> at least if it's a different type than it was at the time the state was
>> saved. For backwards compatibility in case these are pickled it could
>> use the existing format when _inst is the current MT implementation, and
>> accept these in setstate.
>>
>> > It would also be fine for SystemRandom (or
>> > at
>> > least whatever is used by use_secure_random(), if SystemRandom cannot
>> > change for backward compatibility reasons) to raise an exception when
>> > seed(), setstate() or getstate() are called.
>>
>> SystemRandom already raises an exception when getstate and setstate are
>> called.
>>
>> _______________________________________________
>> 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/
>
>
> _______________________________________________
> 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/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150915/ac8b7505/attachment.html>