[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
donald at stufft.io
Fri Jun 10 15:17:47 EDT 2016
> On Jun 10, 2016, at 3:05 PM, David Mertz <mertz at gnosis.cx> wrote:
> OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6?
> It feels to me like the correct spelling in 3.6 should probably be secrets.getrandom() or something related to that.
Well we have https://docs.python.org/dev/library/secrets.html#secrets.token_bytes <https://docs.python.org/dev/library/secrets.html#secrets.token_bytes> so adding a getrandom() function to secrets would largely be the same as that function.
The problem of course is that the secrets library in 3.6 uses os.urandom under the covers, so it’s security rests on the security of os.urandom. To ensure that the secrets library is actually safe even in early boot it’ll need to stop using os.urandom on Linux and use the getrandom() function.
That same library exposes random.SystemRandom as secrets.SystemRandom , and of course SystemRandom uses os.urandom too. So if we want people to treat secrets.SystemRandom as “always secure” then it would need to stop using os.urandom and start using the get random() function on Linux as well.
 This is actually documented as "using the highest-quality sources provided by the operating system” in the secrets documentation, and I’d argue that it is not using the highest-quality source if it’s reading from /dev/urandom or getrandom(GRD_NONBLOCK) on Linux systems where getrandom() is available. Of course, it’s just an alias for random.SystemRandom, and that is documented as using os.urandom.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev