<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 9:07 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Executive summary:<br>
<br>
The question is, "what value is there in changing the default to be<br>
crypto strong to protect future security-sensitive applications from<br>
naive implementers vs. the costs to current users who need to rewrite<br>
their applications to explicitly invoke the current default?"<br></blockquote><div><br></div><div>* [ ] DOC: note regarding the 'pseudo' part of pseudorandom and MT</div><div> * <a href="https://docs.python.org/2/library/random.html">https://docs.python.org/2/library/random.html</a></div><div> * <a href="https://docs.python.org/3/library/random.html">https://docs.python.org/3/library/random.html</a></div><div><br></div><div>* [ ] DOC: upgrade cryptography docs in re: random numbers</div><div> * <a href="https://cryptography.io/en/latest/random-numbers/">https://cryptography.io/en/latest/random-numbers/</a></div><div><br></div><div><br></div><div>* [ ] ENH: random_(algo=) (~IRandomSource)<br></div><div>* [ ] ENH: Add arc4random</div><div>* [ ] ENH: Add chacha</div><div>* [ ] ENH: Add OpenBSD's</div><div><br></div><div><div>* [ ] BUG,SEC: new secure default named random.random</div><div> * must also be stateful / **reproducible** (must support .seed)</div><div> * justified as BUG,SEC because: [secure by default is the answer]</div><div> * <a href="https://en.wikipedia.org/wiki/Session_fixation">https://en.wikipedia.org/wiki/Session_fixation</a></div><div> * <a href="https://cwe.mitre.org/data/definitions/384.html">https://cwe.mitre.org/data/definitions/384.html</a></div><div> * The docs did not say "you should know better."</div><div> * see also: hash collisions: <a href="https://bugs.python.org/issue13703">https://bugs.python.org/issue13703</a></div><div> </div><div> * [ ] REF: random.random -> random.random_old</div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
M.-A. Lemburg writes:<br>
<br>
> I'm pretty sure people doing crypto will know and most others<br>
> simply don't care :-)<br>
<br>
</span>Which is why botnets have millions of nodes. People who do web<br>
security evidently believe that inappropriate RNGs have something to<br>
do with widespread security issues. (That doesn't mean they're right,<br>
but it gives me pause for thought -- evidently, Guido thought so too!)<br>
<span class=""><br>
> Evidence: We used a Wichmann-Hill PRNG as default in random<br>
> for a decade and people still got their work done.<br>
<br>
</span>The question is not whether people get their work done. People work<br>
(unless they're seriously dysfunctional), that's what people do.<br>
Especially programmers (cf. GNU Manifesto). The question is whether<br>
the work of the *crackers* is made significantly easier by security<br>
holes that are opened by inappropriate use of random.random.<br>
<br>
I tend to agree with Steven d'A. (and others) that the answer is no:<br>
it doesn't matter if the kind of person who leaves a key under the<br>
third flowerpot from the left also habitually leaves the door unlocked<br>
(especially if "I'm only gonna be gone for 5 minutes"), and I think<br>
that's likely. IOW, installing crypto strong RNGs as default is *not*<br>
analogous to the changes to SSL support that were so important that<br>
they were backported to 2.7 in a late patch release.<br>
<br>
OTOH, why default to crypto weak if crypto strong is easily available?<br>
You might save a few million Debian users from having to regenerate<br>
all their SSH keys.[1]<br>
<br>
But the people who are "just getting work done" in new programs *won't<br>
notice*. I don't think that they care what's under the hood of<br>
random.random, as long as (1) the API stays the same, and (2) the<br>
documentation clearly indicates where to find PRNGs that support<br>
determinism, jumpahead, replicability, and all those other good<br>
things, for the needs they doesn't have now but know they probably<br>
will have some day. The rub is, as usual, existing applications that<br>
would have to be changed for no reason that is relevant to them.<br>
<br>
Note that arc4random is much simpler to use than random.random. No<br>
knobs to tweak or seeds to store for future reference. Seems<br>
perfectly suited to "just getting work" done to me. OTOH, if you have<br>
an application where you need replicability, jumpahead, etc, you're<br>
going to need to read the docs enough to find the APIs for seeding and<br>
so on. At design time, I don't see why it would hurt to select an<br>
RNG algorithm explicitly as well.<br>
<span class=""><br>
> Why not add ssl.random() et al. (as interface to the OpenSSL<br>
> rand APIs) ?<br>
<br>
</span>I like that naming proposal. I'm sure changing the nature of<br>
random.random would annoy the heck out of *many* users.<br>
<br>
An alternative would be to add random.crypto.<br>
<span class=""><br>
> Some background on why I think deterministic RNGs are more<br>
> useful to have as default than non-deterministic ones:<br>
><br>
> A common use case for me is to write test data generators<br>
> for large database systems. For such generators, I don't keep<br>
> the many GBs data around, but instead make the generator take a<br>
> few parameters which then seed the RNGs, the time module and<br>
> a few other modules via monkey-patching.<br>
<br>
</span>If you've gone to that much effort, you evidently have read the docs<br>
and it wouldn't have been a huge amount of trouble to use a<br>
non-default module with a specified PRNG -- if you were doing it now.<br>
But you have every right to be very peeved if you have a bunch of old<br>
test runs you want to replicate with a new version of Python, and<br>
we've changed the random.random RNG on you.<br>
<br>
<br>
<br>
Footnotes:<br>
[1] I hasten to add that a programmer who isn't as smart as he thinks<br>
he is who "improves" a crypto algorithm is far more likely than that<br>
the implementer of a crypto suite would choose an RNG that is<br>
inappropriate by design. Still, it's a theoretical possibility, and<br>
security is about eliminating every theoretical possibility you can<br>
think of.<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br></div></div>