[Security-sig] Can /dev/urandom ever revert from the "good" to the "bad" state?

[Donald Stufft]

> On Jun 23, 2016, at 11:27 AM, Guido van Rossum <guido at python.org> wrote:
> 
> On Thu, Jun 23, 2016 at 5:42 AM, Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
> On Jun 22, 2016, at 10:37 PM, Donald Stufft wrote:
> 
> >so the question I think really comes down to whether os.urandom is something
> >we want to provide the best source of (generally) non blocking CSPRNG or
> >whether we want it to be a narrow wrapper around whatever semantics
> >/dev/urandom specifically has.
> 
> ... with os.getrandom() exposed on platforms that provide it.
> 
> Personally I think it's better to have one API than two, even if it is named after a platform-specific API.
> 
> FWIW I don't really buy the philosophy that the os module should only provide thin wrappers over what the platform offers. E.g. in the case of Windows most of what's in the os module is part of Microsoft's libc emulation, and the platform APIs have a totally different shape. os.urandom()'s past is already another example. So I don't see a reason to offer two different APIs and force users of those APIs to either commit to a platform or use an ugly try/except. Especially since in Python <= 3.5 they'll only have os.urandom().
> 

For what it’s worth, I agree with this sentiment, though I think calling getrandom() and either blocking or erroring is still a pretty thin wrapper over what the OS provides, it’s just using a different interface to the same underlying functionality with only two real differences (1) Lack of a File Descriptor (2) Inability to get insecure values out of the API, both of which I think are good things. As far as I know, nobody has argued that os.random should *not* use getrandom(), they just want it to fall back to the same behavior as the /dev/urandom does in the (2) case… which is actually a thicker wrapper around what the OS provides than just using getrandom() since that fall back logic needs to be added ;)

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20160623/e3764672/attachment-0001.html>