[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sven R. Kunze]

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>