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

[Nathaniel Smith]

On Mon, Sep 14, 2015 at 3:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 14.09.2015 08:38, Nathaniel Smith wrote:
>> If Tim Peters can get fooled
>> into thinking something like using MT to generate session ids is
>> "probably mostly secure", then what chance do the rest of us have?
>> <wink>
>
> I don't think that Tim can get fooled into believing he is a
> crypto wonk ;-)
>
> The thread reveals another misunderstanding:
>
>  Broken code doesn't get any better when you change the context
>  in which it is run.

As an aphorism this sounds nice, but logically it makes no sense. If
the broken thing about your code is that it assumes that the output of
the RNG is unguessable, and you change the context by making the
output of the RNG unguessable, then now the code it isn't broken.

The code would indeed remain broken when run under e.g. older
interpreters, but this is not an argument that we should make sure
that it stays broken in the future.

> By fixing the RNG used in such broken code and making it
> harder to run attacks, you are only changing the context in which
> the code is run. The code itself still remains broken.
>
> Code which uses the output from an RNG as session id without adding
> any additional security measures is broken, regardless of what kind
> of RNG you are using. I bet such code will also take any session id
> it receives as cookie and trust it without applying extra checks
> on it.

Yes, that's... generally the thing you do with session cookies?
They're shared secret string that you use as keys into some sort of
server-side session database? What extra checks need to be applied?

> Rather than trying to fix up the default RNG in Python by replacing
> it with a crypto RNG, it's better to open bug reports to get the
> broken software fixed.
>
> Replacing the default Python RNG with a new unstudied crypto one,
> will likely introduce problems into working code which rightly
> assumes the proven statistical properties of the MT.
>
> Just think of the consequences of adding unwanted bias to simulations.
> This is far more likely to go unnoticed than a session highjack due
> to a broken system and can easily cost millions (or earn you
> millions - it's all probability after all :-)).

I'm afraid you just don't understand what you're talking about here.

When it comes to adding bias to simulations, all crypto RNGs have
*better* statistical properties than MT. A crypto RNG which was merely
as statistically-well-behaved as MT would be considered totally
broken, because MT doesn't even pass black-box tests of randomness
like TestU01.

> Now, pointing people who write broken code to a new module which
> provides a crypto RNG probably isn't much better either. They'd feel
> instantly secure because it says "crypto" on the box and forget
> about redesigning their insecure protocol as well. Nothing much you
> can do about that, I'm afraid.

Yes, improving the RNG only helps with some problems, not others; it
might merely make a system harder to attack, rather than impossible to
attack. But giving people unguessable random numbers by default does
solve real problems.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org