[Cryptography-dev] OpenSSL Random Engine PR

[Paul Kehrer]

On Monday, January 20, 2014 at 1:26 PM, Jean-Paul Calderone 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...
>  
> 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
I don’t know under what circumstances /dev/urandom reseeds itself on Linux, so I can't answer this question. Greg Price can probably give us an answer as he’s involved with improving the kernel’s RNG. Anyone know if he’s on this list or if we need to ping him on IRC?
>  
>  
> >  
> > 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 (mailto:Cryptography-dev at python.org) https://mail.python.org/mailman/listinfo/cryptography-dev  
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org (mailto: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/9feb9452/attachment.html>