Python and crypto-strength random numbers by default

Posted Sep 17, 2015 8:20 UTC (Thu) by hthoma (subscriber, #4743)
Parent article: Python and crypto-strength random numbers by default

I don't read the documentation either. But if I see an API that has a seed() function, I strongly assume that subsequent calls to random() are deterministic. Just because if it would not be deterministic, then there is no point in having a seed() function at all, IMHO.

Python and crypto-strength random numbers by default

Posted Sep 17, 2015 13:03 UTC (Thu) by njh (subscriber, #4425) [Link] (2 responses)

The tweak that immediately occurred to me would be to change which RNG algorithm is used, based on whether it is explicitly seeded or not.

The article suggest that the existing MT algorithm is seeded from urandom by default, if no seed value is provided.

Why not return values from the MT algorithm if random.random() is called after an explicit seed has been set, but switch to a newer CSPRNG algorithm if random.random() is called without seeding? That would mean that existing Monte Carlo simulation code (and similar) would continue to give results that matched runs from before the change, but stronger random numbers would be produced by default in cases where reproducibility isn't a concern.

Python and crypto-strength random numbers by default

Posted Sep 17, 2015 19:10 UTC (Thu) by droundy (subscriber, #4559) [Link]

This was precisely my thought. It doesn't require changing the documentation at all, as you still should use the explicitly secure one if you need it, to avoid attacks that rely on a module silently degrading random.random. But it "fixes" the vast majority of the naive code out there.

Python and crypto-strength random numbers by default

Posted Sep 17, 2015 21:21 UTC (Thu) by njs (subscriber, #40338) [Link]

> Why not return values from the MT algorithm if random.random() is called after an explicit seed has been set, but switch to a newer CSPRNG algorithm if random.random() is called without seeding?

AFAICT, the only reason not to (besides the usual one that it would take some work to implement and maintain) is that Guido considers it "a hack" :-(