[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)

Paul Moore p.f.moore at gmail.com
Sun Jun 12 07:10:00 EDT 2016


On 11 June 2016 at 22:46, Donald Stufft <donald at stufft.io> wrote:

I guess one question would be, what does the secrets module do if it’s on a Linux that is too old to have getrandom(0), off the top of my head I can think of:

* Silently fall back to reading os.urandom and hope that it’s been seeded. * Fall back to os.urandom and hope that it’s been seeded and add a SecurityWarning or something like it to mention that it’s falling back to os.urandom and it may be getting predictable random from /dev/urandom. * Hard fail because it can’t guarantee secure cryptographic random. Of the three, I would probably suggest the second one, it doesn’t let the problem happen silently, but it still “works” (where it’s basically just hoping it’s being called late enough that /dev/urandom has been seeded), and people can convert it to the third case using the warnings module to turn the warning into an exception.

I have kept out of this discussion as I don't know enough about security to comment, but in this instance I think the answer is clear

By all means document "if your OS provides no means of getting guaranteed secure randon mumbers (e.g., older versions of Linux very early in the boot sequence) then the secrets module cannot give you results that are any better than the OS provides". It seems self-evident to me that this would be the case, but I see no reason to object if the experts feel it's worth adding.

Paul



More information about the Python-Dev mailing list