> On Jun 22, 2016, at 10:29 PM, Guido van Rossum <gu...@python.org> wrote: > > On Wed, Jun 22, 2016 at 7:18 PM, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > >> On Jun 22, 2016, at 10:15 PM, Guido van Rossum <gu...@python.org >> <mailto:gu...@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
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
