On Fri, 10 Jun 2016 at 12:20 Donald Stufft <donald@stufft.io> wrote:
On Jun 10, 2016, at 3:05 PM, David Mertz <mertz@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 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 [1], 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.
[1] 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.
If that's the case then we should file a bug so we are sure this is the case and we need to decouple the secrets documentation from random so that they can operate independently with secrets always doing whatever is required to be as secure as possible.