[Security-sig] Can /dev/urandom ever revert from the "good" to the "bad" state?

Tim Peters tim.peters at gmail.com
Wed Jun 22 22:40:02 EDT 2016


[Guido]
> Before I can possibly start thinking about what to do when the system's
> CSPRNG is initialized, I need to understand more about how it works.
> Apparently there's a possible transition from the "not ready yet" ("bad")
> state to "ready" ("good"), and all it takes is usually waiting for a second
> or two. But is this a wait that only gets incurred once, somewhere early
> after a boot, or is this something that can happen at any time?

[Donald Stufft]
> Once, only after boot. On most (all?) modern Linux systems there’s even part
> of the boot process that attempts to seed the CSPRNG using random values
> stored during a previous boot to shorten the time window between when it’s
> ready and when it’s not yet initialized. However, once it is initialized it
> will never block (or EAGAIN) again.

Donald, at the end you're talking about how getrandom() behaves -
/dev/urandom on Linux never blocks, as I understand it (but there's no
advertised way to tell when /dev/urandom enters the "good" state).


[Guido]
> Then shouldn't it be the responsibility of the boot sequence rather than
> of the Python stdlib to wait for that event? IIUC that's what OS X
> does (I think someone described that it even kernel-panics when it can't
> enter the "good" state).

The rub is that sometimes Python is running soooo early in the boot
sequence in these rare Linux cases.  That's said to be impossible on
OS X (or Windows).


More information about the Security-SIG mailing list