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

[Ian Cordasco]

On Wed, Sep 9, 2015 at 2:07 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, Sep 09, 2015 at 02:55:01PM -0400, random832 at fastmail.us wrote:
>> On Wed, Sep 9, 2015, at 14:31, Tim Peters wrote:
>> > Also over & over again.  If you volunteer to own responsibility for
>> > updating all versions of Python each time it changes (in a crypto
>> > context, an advance in the state of the art implies the prior state
>> > becomes "a bug"), and post a performance bond sufficient to pay
>> > someone else to do it if you vanish, then a major pragmatic objection
>> > would go away ;-)
>>
>> I don't see how "Changing Python's RNG implementation today to
>> arc4random as it exists now" necessarily implies "Making a commitment to
>> guarantee the cryptographic suitability of Python's RNG for all time".
>> Those are two separate things.
>
> Not really. Look at the subject line. It doesn't say "should we change
> from MT to arc4random?", it asks if the default random number generator
> should be secure. The only reason we are considering the change from MT
> to arc4random is to make the PRNG cryptographically secure. "Secure" is
> a moving target, what is secure today will not be secure tomorrow.
>
> Yes, in principle, we could make the change once, then never again. But
> why bother? We don't gain anything from changing to arc4random if there
> is no promise to be secure into the future.

This is a good point. Let's remove the ssl library from Python too.
Until recently, the most widely used versions of Python were all
woefully behind the times and anyone wanting anything relatively
up-to-date had to use a third party library. Even so, if you count the
distributions of RHEL and other "Long Term Support" operating systems
that are running Python 2.7 (pre 2.7.9) and below, most people are
operating with barely secure versions of OpenSSL on versions of Python
that don't have constants for modern secure communications standards.
Clearly, deciding to add the ssl module was a huge mistake because it
wasn't forwards compatible with future security standards.