<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Sep 2015 at 07:22 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On September 10, 2015 at 9:44:13 AM, Paul Moore (<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>) wrote:<br>
> On 10 September 2015 at 14:10, Donald Stufft wrote:<br>
> >> I don't understand the phrase "if you needed determinism, it would<br>
> >> hurt you to say so". Could you clarify?<br>
> ><br>
> > I transposed some words, fixed:<br>
> ><br>
> > "If you needed determinism, would it hurt you to say so?""<br>
><br>
> Thanks.<br>
><br>
> In one sense, no it wouldn't. Nor would it matter to me if "the<br>
> default random number generator" was fast and cryptographically<br>
> secure. What matters is just that I get a load of random (enough)<br>
> numbers.<br>
><br>
> What hurts somewhat (not enormously, I'll admit) is up front having to<br>
> think about whether I need to be able to capture a seed and replay it.<br>
> That's nearly always something I'd think of way down the line, as a<br>
> "wouldn't it be nice if I could get the user to send me a reproducible<br>
> test case" or something like that. And of course it's just a matter of<br>
> switching the underlying RNG at that point.<br>
> <br>
> None of this is hard. But once again, I'm currently using the module<br>
> correctly, as documented.<br>
<br>
This is actually exactly why Theo suggested using a modern, userland CSPRNG<br>
because it can generate random numbers faster than /dev/urandom can and, unless<br>
you need deterministic results, there's little downside to doing so. <br>
<br>
There's really two possible ideas here that depends on what sort of balance<br>
we'd want to strike. We can make a default "I don't want to think about it"<br>
implementation of random that is both *generally* secure and fast, however it<br>
won't be deterministic and you won't be able to explicitly seed it. This would<br>
be a backwards compatible change [1] for people who are simply calling these<br>
functions [2]:<br>
<br>
random.getrandbits<br>
random.randrange<br>
random.randint<br>
random.choice<br>
random.shuffle<br>
random.sample<br>
random.random<br>
random.uniform<br>
random.triangular<br>
random.betavariate<br>
random.expovariate<br>
random.gammavariate<br>
random.gauss<br>
random.lognormvariate<br>
random.normalvariate<br>
random.vonmisesvariate<br>
random.paretovariate<br>
random.weibullvariate<br>
<br>
If this were all that the top level functions in random.py provided we could<br>
simply replace the default and people wouldn't notice, they'd just<br>
automatically get safer randomness whether that's actually useful for their<br>
use case or not.<br>
<br>
However, random.py also has these functions:<br>
<br>
random.seed<br>
random.getstate<br>
random.setstate<br>
random.jumpahead<br>
<br>
and these functions are where the problem comes. These functions only really<br>
make sense for deterministic sources of random which are not "safe" for use<br>
in security sensitive applications. So pretending for a moment that we've<br>
already decided to do "something" about this, the question boils down to what<br>
do we do about these 4 functions. Either we can change the default to a secure<br>
CSPRNG and break these functions (and the people using them) which is however<br>
easily fixed by changing ``import random`` to<br>
``import random; random = random.DeterministicRandom()`` or we can deprecate<br>
the top level functions and try to guide people to choose up front what kind<br>
of random they need. Either of these solutions will end up with people being<br>
safer and, if we pretend we've agreed to do "something", it comes down to<br>
whether we'd prefer breaking compatability for some people while keeping a<br>
default random generator that is probably good enough for most people, or if<br>
we'd prefer to not break compatability and try to push people to always<br>
deciding what kind of random they want.<br></blockquote><div><br></div><div>+1 for deprecating module-level functions and putting everything into classes to force a choice<br></div><div>+0 for deprecating the seed-related functions and saying "the stdlib uses was it uses as a RNG and you have to live with it if you don't make your own choice" and switching to a crypto-secure RNG.<br></div><div>-0 leaving it as-is</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course, we still haven't decided that we should do "something", I think that<br>
we should because I think that secure by default (or at least, not insecure by<br>
default) is a good situation to be in. Over the history of computing it's been<br>
shown that time and time again that trying to document or educate users is<br>
error prone and doesn't scale, but if you can design APIs to make the "right"<br>
thing obvious and opt-out and require opting in to specialist [3] cases which<br>
require some particular property.<br>
<br>
<br>
[1] Assuming Theo's claim of the speed of the ChaCha based arc4random function<br>
is accurate, which I haven't tested but I assume he's smart enough to know<br>
what he's talking about WRT to speed of it.<br>
<br>
[2] I believe anyways, I don't think that any of these rely on the properties<br>
of MT or a deterministic source of random, just a source of random.<br>
<br>
[3] In this case, their are two specialist use cases, those that require<br>
deterministic results and those that require specific security properties<br>
that are not satisified by a userland CSPRNG because a userland CSPRNG is<br>
not as secure as /dev/urandom but is able to be much faster.<br>
<br>
><br>
> I've omitted most of the rest of your response largely because we're<br>
> probably just going to have to agree to differ. I'm probably too worn<br>
> out being annoyed at the way that everything ends up needing to be<br>
> security related, and the needs of people who won't read the docs<br>
> determines API design, to respond clearly and rationally :-(<br>
><br>
> Paul<br>
><br>
<br>
-----------------<br>
Donald Stufft<br>
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">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></blockquote></div></div>