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