<div dir="ltr">I don't think we should add a new function. I think we should convince ourselves that there is not enough of a risk of an exploit even if os.urandom() falls back.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 6:03 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jun 9, 2016 at 3:22 PM, Larry Hastings <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
><br>
> On 06/09/2016 08:52 AM, Guido van Rossum wrote:<br>
><br>
>> That leaves direct calls to os.urandom(). I don't think this should block<br>
>> either.<br>
><br>
><br>
> Then it's you and me against the rest of the world ;-)<br>
><br>
><br>
> Okay, it's decided: os.urandom() must be changed for 3.5.2 to never block on<br>
> a getrandom() call. It's permissible to take advantage of<br>
> getrandom(GRND_NONBLOCK), but if it returns EAGAIN we must read from<br>
> /dev/urandom.<br>
><br>
> It's already well established that this will upset the cryptography experts.<br>
> As a concession to them, I propose adding a simple! predictable! function to<br>
> Python 3.5.2: os.getrandom(). This would be a simple wrapper over<br>
> getrandom, only available on platforms that expose it. It would provide a<br>
> way to use both extant flags, GRND_RANDOM and GRND_NONBLOCK, though<br>
> possibly not exactly mirroring the native API.<br>
><br>
> This would enable cryptography libraries to easily do what (IIUC) they<br>
> regard as the "correct" thing on Linux for all supported versions of Python:<br>
><br>
> if hasattr(os, "getrandom"):<br>
> bits = os.getrandom(n)<br>
> else:<br>
> bits = os.urandom(n)<br>
<br>
</span>So I understand that the trade-offs between crypto users and regular<br>
users are tricky, but this resolution concerns me quite a bit :-(<br>
<br>
Specifically, it seems to me that:<br>
1) we now have these two functions that need to be supported forever,<br>
and AFAICT in every case where someone is currently explicitly calling<br>
os.urandom and the behavior differs, they want os.getrandom instead.<br>
(This is based on the assumption that the only time that explicitly<br>
calling os.urandom is the best option is when one cares about the<br>
cryptographic strength of the result -- I'm explicitly distinguishing<br>
here between the hash seeding issue that triggered the original bug<br>
report and explicit calls to os.urandom.) So in practice this change<br>
makes it so that the only correct way of calling either of these<br>
functions is the if/else stanza above.<br>
2) every piece of security-sensitive software is going to spend<br>
resources churning their code to implement the above,<br>
3) every future security audit of Python software is going to spend<br>
resources making sure this is on their checklist of incredibly subtle<br>
gotchas that have to be audited for,<br>
4) the crypto folks are going to have to spin up a whole evangelism<br>
effort to re-educate everyone that (contrary to what we've been<br>
telling everyone for years), os.urandom is no longer the right way to<br>
get cryptographic randomness.<br>
<br>
OTOH if we allow explicit calls to os.urandom to block or raise an<br>
exception, then AFAICT from this thread this will break exactly zero<br>
projects.<br>
<br>
Maybe this is just rehashing the same things that have already been<br>
discussed ad naseaum, in which case I apologize. But I really feel<br>
like this is one of those cases where the crypto folks aren't so much<br>
saying "oh BUT what if <incredibly unlikely situation involving<br>
oppressive regimes and ticking bombs>"; they're more saying "oh $#@<br>
you're going to cause me a *massive* amount of real work and churn and<br>
ongoing costs for no perceivable gain and I'm exhausted even thinking<br>
about it".<br>
<span class=""><br>
> I'm not excited about adding a new function in 3.5.2, but on the other hand<br>
> we are taking away this functionality they had in 3.5.0 and 3.5.1 so only<br>
> seems fair. And the implementation of os.getrandom() should be very<br>
> straightforward, and its semantics will mirror the native call, so I'm<br>
> pretty confident we can get it solid in a couple of days, though we might<br>
> slip 3.5.2rc1 by a day or two.<br>
><br>
> Guido: do you see this as an acceptable compromise?<br>
><br>
> Cryptographers: given that os.urandom() will no longer block in 3.5.2, do<br>
> you want this?<br>
><br>
><br>
> Pointing out an alternate approach: Marc-Andre Lemburg proposes in issue<br>
> #27279 ( <a href="http://bugs.python.org/issue27279" rel="noreferrer" target="_blank">http://bugs.python.org/issue27279</a> ) that we should add two "known<br>
> best-practices" functions to get pseudo-random bits; one merely for pseudo<br>
> random bits, the other for crypto-strength pseudo random bits. While I<br>
> think this is a fine idea, the exact spelling, semantics, and per-platform<br>
> implementation of these functions is far from settled, and nobody is<br>
> proposing that we do something like that for 3.5.<br>
<br>
</span>We already have a function for non-crypto-strength pseudo-random bits:<br>
random.getrandbits. os.urandom is the one for the cryptographers (I<br>
thought).<br>
<span class="HOEnZb"><font color="#888888"><br>
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>