[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Steven D'Aprano steve at pearwood.info
Thu Jun 9 13:49:27 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Jun 09, 2016 at 06:21:32PM +0100, Paul Moore wrote:
If we put the specific issue of applications that run very early in system startup to one side, is there a possibility of running out of entropy during normal system use? Even for a tiny duration?
With /dev/urandom, I believe the answer to that is no.
On most platforms other than Linux, /dev/urandom is exactly the same as /dev/random, and both can only block straight after the machine has booted up before enough entropy has been collected. Then they will run forever without blocking. (Or at least until you reboot.)
On Linux, /dev/random will block, at unpredictable times, but fortunately we're not using /dev/random. We're using Urandom. Apart from just after boot up, /dev/urandom on Linux will also run forever without blocking, just like the other platforms.
The critical difference is just after booting up:
Linux /dev/urandom doesn't block, but it might return predictable, poor-quality pseudo-random bytes (i.e. a potential exploit);
Other OSes may block for potentially many minutes (i.e. a potential DOS).
Two links which may help explain what's happening:
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
http://security.stackexchange.com/a/42955
-- Steve
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]