<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 16, 2015 at 8:47 AM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Guido]<br>
<span class="">> There's still way too much chatter, and a lot that seems just rhetoric. This<br>
> is not the republican primaries.<br>
<br>
</span>Which is a shame, since the chatter here is of much higher quality<br>
than in the actual primaries ;-)<br>
<span class=""><br>
<br>
> Yes lots of companies got hacked. What's the evidence that a language's<br>
> default RNG was involved?<br>
<br>
</span>Nobody cares whether there's evidence of actual harm.  Just that there<br>
_might_ be, and even if none identifiable now, then maybe in the<br>
future.<br>
<br>
There is evidence of actual harm from RNGs doing poor _seeding_ by<br>
default, but Python already fixed that (I know, you already know that<br>
;-) ).<br>
<br>
And this paper, from a few years ago, studying RNG vulnerabilities in<br>
PHP apps, is really good:<br>
<br>
     <a href="https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf" rel="noreferrer" target="_blank">https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf</a><br>
<br>
An interesting thing is that several of the apps already had a history<br>
of trying to fix security-related holes related to RNG (largely due to<br>
PHP's poor default seeding), but remained easily cracked.<br>
<br>
The primary recommendation there wasn't to make PHP's various PRNGs<br>
"crypto by magic", but for core PHP to supply "a standard" crypto RNG<br>
for people to use instead.  As above, some of the app developers<br>
already knew darned well they had a history of RNG-related holes, but<br>
simply had no standard way to address it, and didn't have the _major_<br>
expertise needed to roll their own.<br>
<span class=""><br>
<br>
> IIUC the best practice for password encryption (to<br>
> make cracking using a large word list harder) is something called bcrypt;<br>
> maybe next year something else will become popular, but the default RNG<br>
> seems an unlikely candidate. I know that in the past the randomness of<br>
> certain protocols was compromised because the seeding used a timestamp that<br>
> an attacker could influence or guess. But random.py seeds MT from<br>
> os.urandom(2500). So what's the class of vulnerabilities where the default<br>
> RNG is implicated?<br>
<br>
</span>1. Users doing their own poor seeding.<br>
<br>
2. A hypothetical MT state-deducer (seemingly needing to be<br>
   considerably more sophisticated than the already mondo<br>
   sophisticated one in the paper above) to be of general use<br>
   against Python.<br>
<br>
3. "Prove there can't be any in the future.  Ha!  You can't." ;-)<br>
<span class=""><br>
<br>
> Tim's proposal is simple: create a new module, e.g. safefandom, with the<br>
> same API as random (less seed/state). That's it. Then it's a simple import<br>
> change away to do the right thing, and we have years to seed StackOverflow<br>
> with better information before that code even hits the road. (But a backport<br>
> to Python 2.7 could be on PyPI tomorrow!)<br>
<br>
</span>Which would obviously be fine by me:  make the distinction obvious at<br>
import time, make "the safe way" dead easy and convenient to use, give<br>
it anew name engineered to nudge newbies away from the "unsafe" (by<br>
contrast) `random`, and a new name easily discoverable by web search.<br>
<br>
There's something else here:  some of these messages gave pointers to<br>
web pages where "security wonks" conceded that specific uses of<br>
SystemRandom were fine, but they couldn't recommend it anyway because<br>
it's too hard to explain what is or isn't "safe".  "Therefore" users<br>
should only use urandom() directly.  Which is insane, if for no other<br>
reason than that users would then invent their own algorithms to<br>
convert urandom() results into floats and ints, etc.  Then they'll<br>
screw up _that_ part.<br>
<br>
But if "saferandom" were its own module, then over time it could<br>
implement its own "security wonk certified" higher level (than raw<br>
bytes) methods.  I suspect it would never need to change anything from<br>
what the SystemRandom class does, but I'm not a security wonk, so I<br>
know nothing.  Regardless, _whatever_ changes certified wonks deemed<br>
necessary in the future could be confined to the new module, where<br>
incompatibilities would only annoy apps using that module.  Ditto<br>
whatever doc changes were needed.  Also gone would be the inherent<br>
confusion from needing to draw distinctions between "safe" and<br>
"unsafe" in a single module's docs (which any by-magic scheme would<br>
only make worse).<br>
<br>
However, supplying a powerful and dead-simple-to-use new module would<br>
indeed do nothing to help old code entirely by magic.  That's a<br>
non-goal to me, but appears to be the _only_ deal-breaker goal for the<br>
advocates.<br>
<br>
Which is why none of us is the BDFL ;-)<br>
</blockquote></div><br></div><div class="gmail_extra">So if you or someone else (Chris?) wrote that up in PEP form I'd accept it.<br><br></div><div class="gmail_extra">I'd even accept adding a warning on calling seed() (but not setstate()).<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>