Confusion about os.urandom()
Hello there. I was just reading through http://www.python.org/2.4/highlights.html and noticed the following: os.urandom() has been added for systems that support a source of random data (entropy) At first, I was a bit stunned about the choice of name here. Why would anyone call this method urandom()? That confused me a bit, for, AFAICS, under Linux at least, /dev/random is the entropy pool and /dev/urandom is a PRNG (or rather, a source of random numbers which falls back to a PRNG when the entropy pool runs out of numbers). So I would not expect a method that is supposed to yield cryptographically secure random numbers to be called `urandom()'. Anyway, that might be non-intuitive (which is unusual in Python), but certainly not a severe bug. But then I noticed that if I rename /dev/urandom to something else (say, /dev/notrandomenough), os.urandom() (in Python 2.4b2) raises a NotImplementedError: Python 2.4b2 (#2, Nov 11 2004, 23:44:54) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Now I'm really confused. Does os.urandom() use /dev/urandom under Linux? Either my brain has got a serious bug that makes me misunderstand the random(4) manpage, which states that "[w]hen read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver", or the implementation of os.urandom() is severely flawed. (BTW, I just checked Python 2.4c1. Judging from the source code, it seems to have the same behaviour.) That's what help(os.urandom) says: urandom(n) -> str Return a string of n random bytes suitable for cryptographic use. So it should be using /dev/random rather than /dev/urandom, shouldn't it? - Matthias A. Benkard
Matthias Andreas Benkard wrote:
That is not true. It doesn't first exhaust the pool and then falls back to PRNG. Instead, it gradually moves to a PRNG, depending on the amount of entropy in the pool. The values returned are still cryptographically secure, except in purely theoretical cases (where a lot of entropy is drawn from random or urandom, and nothing is filled in).
Now I'm really confused. Does os.urandom() use /dev/urandom under Linux?
Yes, it does.
No, it shouldn't. /dev/random may block, which os.urandom() will not. The name urandom deliberately tells users that there is a theoretical flaw (which is practically irrelevant). If users cannot stand the theoretical flaw, they need to use /dev/random (which also has theoretical flaws that just happen to be even less practically relevant). In that case a) they have to accept that reading /dev/random might block indefinitely, and b) their code will become more system-dependent. Regards, Martin
Matthias Andreas Benkard wrote:
That is not true. It doesn't first exhaust the pool and then falls back to PRNG. Instead, it gradually moves to a PRNG, depending on the amount of entropy in the pool. The values returned are still cryptographically secure, except in purely theoretical cases (where a lot of entropy is drawn from random or urandom, and nothing is filled in).
Now I'm really confused. Does os.urandom() use /dev/urandom under Linux?
Yes, it does.
No, it shouldn't. /dev/random may block, which os.urandom() will not. The name urandom deliberately tells users that there is a theoretical flaw (which is practically irrelevant). If users cannot stand the theoretical flaw, they need to use /dev/random (which also has theoretical flaws that just happen to be even less practically relevant). In that case a) they have to accept that reading /dev/random might block indefinitely, and b) their code will become more system-dependent. Regards, Martin
participants (2)
-
"Martin v. Löwis" -
Matthias Andreas Benkard