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

[Robert Kern]

On 2015-09-16 01:43, Tim Peters wrote:
> ...
>
> [Marc-Andre]
>> Ah, now we're getting somewhere :-)
>>
>> If we accept that non-guessable, but deterministic is a good
>> compromise, then adding a cipher behind MT sounds like a reasonable
>> way forward, even as default.
>>
>> For full crypto strength, people would still have to rely on
>> solutions like /dev/urandom or the OpenSSL one (or reseed the
>> default RNG every now and then). All others get the benefit of
>> non-guessable, but keep the ability to seed the default RNG in
>> Python.
>
> I expect the only real reason "new entropy" is periodically mixed in
> to OpenBSD's arc4random() is to guard against that a weakness in
> ChaCha20 may be discovered later.  If there were any known
> computationally feasible way whatsoever to distinguish bare-bones
> ChaCha20's output from a "truly random" sequence, it wouldn't be
> called "crypto" to begin with.

Periodic reseeding also serves to guard against other leaks of information about 
the underlying state that don't come from breaking through the cipher. If an 
attacker manages to deduce the state through side channels, timing attacks on 
the machine, brief physical access, whatever, then reseeding with new entropy 
will limit the damage rather than blithely continuing on with a compromised 
state forever.

It's an important feature of a CSPRNG. Using a crypto output function in your 
PRNG is a necessary but not sufficient condition for security.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco