[Cryptography-dev] OpenSSL Random Engine PR

[Paul Kehrer]

Is anyone aware of blockers around the urandom engine PR (https://github.com/pyca/cryptography/pull/377) at this point? We’ve solicited feedback from as many people as we can and it appears this approach is generally considered to be a good one. What do we need to do to get this landed?  


For those desiring a refresher, OpenSSL has a CSPRNG that it seeds when starting up. Unfortunately, this state is then replicated if the process is forked and child processes can deliver similar/identical random values[1]. This issue came up for CPython (http://bugs.python.org/issue18747), but the solution of reseeding on pthread_atfork turns out to be dangerous and was backed out.

The solution we’ve come up with is to build an OpenSSL engine that replaces the standard random source with one that fetches entropy from /dev/urandom (or CryptGenRandom on Windows, which is Fortuna).

Advantages to this approach:
* Fixes fork issue
* Gets entropy from a source many (most?) cryptographers consider less likely to have serious issues than a userland RNG.

Disadvantages:
* Slower than OpenSSL’s native generation (this doesn’t seem to be an issue, but is worth noting)
* Affects global OpenSSL state

The last one means that when activating this engine anything in the same process that is using OpenSSL will switch to this engine. That includes Python’s own SSL module (unless cryptography is built against an alternate OpenSSL).

The current codebase registers the engine in the binding, but does not activate it. The backend activates it. This means consumers of the binding only (e.g. PyOpenSSL) will not use the engine unless they explicitly opt-in.

[1] OpenSSL has put in some mitigation for this problem in trunk (not sure if it was released with 1.0.1f), but we can’t rely on that.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140120/74f6aa9a/attachment-0001.html>