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

[Nick Coghlan]

On 11 September 2015 at 12:07, 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?"
>
> 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!)

They're right. I used to be sanguine about this kind of thing because
I spent a long time working in the defence sector, and assumed
everyone else was as professionally paranoid as we were. I've been out
of that world long enough now to realise that that assumption was
deeply, and problematically, wrong*.

In that world, you work on the following assumptions: 1) you're an
interesting target; 2) the attackers' compute capacity is nigh
infinite; 3) any weakness will be found; 4) any weakness will be
exploited; 5) "other weaknesses exist" isn't a reason to avoid
addressing the weaknesses you know about.

As useful background, there's a recent Ars Technica article on the
technical details of cracking the passwords in the Ashley Madison data
dump, where security researchers found a NINE order of magnitude
speedup due to a vulnerability in another part of the system which let
them drastically reduce the search space for passwords:
http://arstechnica.com/security/2015/09/once-seen-as-bulletproof-11-million-ashley-madison-passwords-already-cracked/

That kind of reduction in search requirements means that searches that
*should* have taken almost 3000 years (in the absence of the
vulnerability) can instead be completed within a day.

Weak random number generators have a similar effect of reducing the
search space for attackers - if you know a weakly random source was
used, rather than a cryptographically secure one, then you can use
what you know about the random number generator to favour inputs it is
*likely* to have produced, rather than having to assume equal
probability for the entire search space. And if the target was using a
deterministic RNG and you're able to figure out the seed that was
used? You no longer need to search at all - you can recreate the exact
series of numbers the target was using.

Moving the default random source to a CSPRNG, and allowing folks to
move a faster deterministic PRNG for known non-security related use
cases, or to the system random number generator for known
security-related ones is likely to prove a good way to provide safer
defaults without reducing flexibility or raising barriers to entry too
much.

Regards,
Nick.

P.S. * As a case in point, it was only a couple of years ago that I
realised most developers *haven't* read docs like the NIST crypto
usage guidelines or the IEEE 802.11i WPA2 spec, and don't make a habit
of even casually following the progress of block cipher and secure
hash function design competitions. It's been an interesting exercise
for me in learning the true meaning of "expertise is relative" :)


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia