[Python-ideas] Should our default random number generator be secure?

[Wes Turner]

On Thu, Sep 10, 2015 at 9:07 PM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> 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
  * https://docs.python.org/2/library/random.html
  * https://docs.python.org/3/library/random.html

* [ ] DOC: upgrade cryptography docs in re: random numbers
  * https://cryptography.io/en/latest/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]
    * https://en.wikipedia.org/wiki/Session_fixation
      * https://cwe.mitre.org/data/definitions/384.html
        * 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.[1]
>
> 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.
>
>
>
> Footnotes:
> [1]  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
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150911/ec59fdeb/attachment-0001.html>