[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
Sven R. Kunze
srkunze at mail.de
Fri Jun 10 15:45:13 EDT 2016
More information about the Python-Dev mailing list
Fri Jun 10 15:45:13 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 10.06.2016 21:17, Donald Stufft wrote: > >> On Jun 10, 2016, at 3:05 PM, David Mertz <mertz at gnosis.cx >> <mailto: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. > I am not a security expert but your reply makes it clear to me. So, for me this makes: os -> os-dependent and because of this varies from os to os (also quality-wise) random -> pseudo-random, but it works for most non-critical use-cases secret -> that's for crypto If don't need crypto, secret would be a waste of resources, but if you need crypto, then os and random are unsafe. I think that's simple enough. At least, I would understand it. Just my 2 cents: if I need crypto, I would pay the price of blocking rather then to get an exception (what are my alternatives? I need those bits! ) or get unsecure bits. Sven > 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. > > — > Donald Stufft > > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160610/29416d75/attachment.html>
- 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 ]
More information about the Python-Dev mailing list