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

[Donald Stufft]

> On Jun 22, 2016, at 10:29 PM, Guido van Rossum <guido at python.org> wrote:
> 
> On Wed, Jun 22, 2016 at 7:18 PM, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> 
>> On Jun 22, 2016, at 10:15 PM, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
>> 
>> 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?
> 
> 
> 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.
> 
> 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).
> 

In an ideal world? Yes. However we live in a not ideal world where Linux doesn’t ensure that, so absent Linux deciding to do something like what OS X, FreeBSD, Windows, OpenBSD, etc do we have to make a choice, either we pass along the possibility that Linux left us with, and make it so people who attempt to use Python early in the boot sequence can get predictable random numbers (without any way to determine if they’re getting “good” or “bad” numbers) or we use the newer API that Linux has given us to make that assurance.

AFAIK Linux (or, well Ted) has stated that the way for people who care about getting cryptographically secure random out of the kernel is to use getrandom(0) (or getrandom(GRDB_NONBLOCK) and fail on an EAGAIN) so the question I think really comes down to whether os.urandom is something we want to provide the best source of (generally) non blocking CSPRNG or whether we want it to be a narrow wrapper around whatever semantics /dev/urandom specifically has.

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20160622/86f2d372/attachment-0001.html>