[openssl-dev] Weak DH and the Logjam

[Kurt Roeckx]

On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote:
> On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote:
> > On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote:
> > > Hello.
> > > 
> > > Given Adrien et al. recent paper [1] together with their
> > > proof-of-concept attacks against 512-bit DH groups [2], it might be
> > > a good time to resurrect a discussion Daniel Kahn Gillmor has
> > > started here in the past.
> > 
> > Please see
> > http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
> > 
> > 
> > Kurt
> 
> Hi Kurt. Thanks for the link and congrats to EK for a well-written blog.
> 
> A few questions...
> 
> 1. On ECC:
> 
> Did I correctly understand that starting with 1.0.2b, OpenSSL clients
> will only include secp256r1, secp384r1, and secp521r1 on the prime side
> and sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 on
> the binary side in supported elliptic curves extensions?

It also has the 3 brainpool curves and secp256k1.

It looks like this:
/* The client's default curves / the server's 'auto' curves. */
static const unsigned char eccurves_auto[] = {
    /* Prefer P-256 which has the fastest and most secure implementations. */
    0, 23,                      /* secp256r1 (23) */
    /* Other >= 256-bit prime curves. */
    0, 25,                      /* secp521r1 (25) */
    0, 28,                      /* brainpool512r1 (28) */
    0, 27,                      /* brainpoolP384r1 (27) */
    0, 24,                      /* secp384r1 (24) */
    0, 26,                      /* brainpoolP256r1 (26) */
    0, 22,                      /* secp256k1 (22) */
    /* >= 256-bit binary curves. */
    0, 14,                      /* sect571r1 (14) */
    0, 13,                      /* sect571k1 (13) */
    0, 11,                      /* sect409k1 (11) */
    0, 12,                      /* sect409r1 (12) */
    0, 9,                       /* sect283k1 (9) */
    0, 10,                      /* sect283r1 (10) */
};

> Will OpenSSL consider making this change in 1.0.1 as well?

1.0.1 doesn't support the auto ecdh, so we at least can't do
exactly the same there.  But maybe we should also update the
default used by the client?

> 2. On FF DH:
> 
> Is it possible for OpenSSL to provide a tentative timeline for its
> planned transition (no minimum -> 768-bit min -> 1024-bit min)? Right
> now the move to 1024-bit is slated for "soon" but tentative dates are
> likely more effective prods for sites (and others) using Jurassic
> modp's.

We haven't set any dates for anything yet.  But the 768 minimum
requirement is currently in the various branches in git.  Master
even has had 1024 as default for a while.


Kurt