[Cryptography-dev] OpenSSL Random Engine PR

[Jean-Paul Calderone]

On 01/20/2014 12:36 PM, Paul Kehrer wrote:
> 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).

Won't this make OpenSSL suck up all entropy on a system fairly easily? 
For example, every SSL handshake requires some random bytes (I could
count them I guess but it doesn't really matter).  Consider an HTTPS
server accepting hundreds of requests per second...

Since the idea is to use urandom, this won't cause a problem as obvious
as blocking the SSL server waiting for more entropy.  It will exhaust
what the system (at least on Linux, I don't know much about urandom on
other platforms) considers the actual amount of available entropy.  This
may mean that any other process that really wants /dev/random may be
unable to operate.

Jean-Paul


>
> 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.
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140120/939c5b0d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140120/939c5b0d/attachment.sig>