[Cryptography-dev] OpenSSL Random Engine PR

[Laurens Van Houtven]

On Jan 20, 2014 9:11 PM, "Jean-Paul Calderone" <jean-paul at hybridcluster.com>
wrote:
>
> 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...

On phone, so brief, but: no.

> 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
>
>
>
> _______________________________________________
> 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/15587c97/attachment-0001.html>