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

[Cory Benfield]

> On 9 Jun 2016, at 12:54, Christian Heimes <christian at python.org> wrote:
> 
> Therefore I propose to fix problem 2 and 3:
> 
> - add a new random_seed member to _Py_HashSecret and use it to derive an
> initial Mersenne-Twister state for the default random instance of the
> random module.
> 
> - try CPRNG for _Py_HashSecret first, fall back to a user space RNG when
> the Kernel's CPRNG would block.
> 
> For some operating systems like Windows and OSX, we can assume that
> Kernel CPRNG is always available. For Linux we can use getrandom() in
> non-blocking mode and handle EWOULDBLOCK. On BSD the seed state can be
> queried from /proc.
> 

I am in agreement with Christian here.

Let me add: Larry has suggested that it’s ok that os.urandom() can degrade to weak random numbers in part because "os.urandom() doesn't actually guarantee it's suitable for cryptography.” That’s true, that is what the documentation says.

However, that documentation has been emphatically disagreed with by the entire Python ecosystem *including* the Python standard library. Both random.SystemRandom and the secrets module use os.urandom() to generate their random numbers. The secrets module says this right at the top:

"The secrets module is used for generating cryptographically strong random numbers suitable for managing data such as passwords, account authentication, security tokens, and related secrets.”

Regressing the behaviour in os.urandom() would mean that this statement is not unequivocally true but only situationally true. It would be more accurate to say “The secrets module should generate cryptographically strong random numbers most of the time”. So I’d argue that while os.urandom() does not make these promises, the rest of the standard library behaves like it does. While we’re here I should note that the cryptography project unequivocally recommends os.urandom[0], and that this aspect of Linux’s /dev/urandom behaviour is considered to be a dangerous misfeature by almost everyone in the crypto community.

The Linux kernel can’t change this stuff easily because they mustn’t break userspace. Python *is* userspace, we can do what we like, and we should be aiming to make sure that doing the obvious thing in Python amounts to doing the *right* thing. *Obviously* this shouldn’t block startup, and obviously we should fix that, but I disagree that we should be reverting the change to os.urandom().

Cory

[0]: https://cryptography.io/en/latest/random-numbers/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160609/8db8cf90/attachment.sig>