<div dir="ltr">Clearly I need to mute this thread too. :-(<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 15, 2015 at 9:09 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr">On Sep 15, 2015 1:19 PM, "Guido van Rossum" <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
><br>
> 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.</p>
</span><p dir="ltr">If we have a fast secure RNG, then the standard Random object might as well at least use it by default until someone actually sets or reads the state (and then switch to MT at that point). Until one of these events happens, the two RNGs are indistinguishable, and this would be a 100% backwards compatible change. (It might even make sense to backport to 2.7.)</p>
<p dir="ltr">The limitation is that if library A uses the global random object without seeding in a security sensitive context, and library B uses seeding, then a program that just uses library A will be secure, but if it then starts using library B it will become insecure. But this is still better than the current situation where library A is always insecure.</p>
<p dir="ltr">The only case where this would actually have a downside compared to status quo (assuming arc4random lives up to it's reputation for speed etc) is if people start assuming that the default random object is in fact secure and intentionally choosing to use it in security sensitive situations. But hopefully people who know enough to realize that this is a decision they need to make will also read the docs where it clearly states that this is only a best-effort kind of hardening mechanism and that using random.Random/the global methods for cryptographic purposes is still a bug.</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">-n<br>
</p>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>