Hi Jan-Just,

> -----Original Message-----
> From: Jan Just Keijser [mailto:janj...@nikhef.nl]
> Adriaan de Jong wrote:
> >
> > On 02/07/2012 04:13 PM, Jan Just Keijser wrote:
> >>

<Snip>

> >> +void
> >> +tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, const char
> *curve_name
> >> +    )
> >> +{
> >> +#ifdef USE_SSL_EC
> >> +  if (curve_name != NULL)
> >> +  {
> >> +    int nid;
> >> +    EC_KEY   *ecdh  = NULL;
> >> +
> >> +    nid = OBJ_sn2nid(curve_name);
> >> +
> >> +    if (nid == 0)
> >> +      msg(M_SSLERR, "unknown curve name (%s)", curve_name);
> >> +    else
> >> +    {
> >> +      ecdh = EC_KEY_new_by_curve_name(nid);
> >> +      if (ecdh == NULL)
> >> +        msg (M_SSLERR, "Unable to create curve (%s)", curve_name);
> >> +      else
> >> +      {
> >> +        const char *sname;
> >> +
> >> +        if (!SSL_CTX_set_tmp_ecdh(ctx->ctx, ecdh))
> >> +          msg (M_SSLERR, "SSL_CTX_set_tmp_ecdh: cannot add curve");
> >> +
> >>
> >
> > What is happening here exactly? Is the same key being reused for
> every
> > connection, or is it magically regenerated by OpenSSL on every
> connection?
> >
> >
> the function SSL_CTX_set_tmp_ecdh is very similar to SSL_CTX_set_tmp
> (for DH keys).
> It adds the curve to the SSL CTX (ConTeXt); this CTX is used only when
> negotiating the TLS channel - NOT the data channel. It is updated by
> the OpenSSL TLS code automagically.

Thanks, I realise this is just about the control channel. Still: for a server 
setup, multiple control channels are set up (one for each connection). 

What I'm reading here, but that could be a mistake is the following:

1. Determine Curve NID
2. Generate a new DH key based on the curve NID (ecdh = 
EC_KEY_new_by_curve_name(nid);)
3. For the global context, set that key as the one be used. 

Now, if that is correct, the same key is reused across multiple connections for 
a server setup. 

Again, note that my assumptions here might be incorrect, especially in step 2. 
Unfortunately, I can't find decent documentation for the OpenSSL functions.

> >> +        /* Translate NID back to name , just for kicks */
> >> +        sname   = OBJ_nid2sn(nid);
> >> +        if (sname == NULL) sname = "(Unknown)";
> >> +        msg (D_TLS_DEBUG_LOW, "ECDH curve %s added", sname);
> >> +
> >> +        EC_KEY_free(ecdh);
> >> +      }
> >> +    }
> >> +  }
> >> +#else
> >> +  msg(M_SSLERR, "Elliptic Curves not supported by this version of
> >> +OpenSSL"); #endif }
> >> +

<Snip>

> >
> > Codewise I don't have many comments. I do have a few questions
> > surrounding the use of OpenSSL:
> >
> >  - How are curves for ECDSA set?
> >
> >  - Is the default curve used, or is the same curve reused?
> >
> >  - I don't quite understand how setting an ECDH curve relates to the
> > ECDSA signature size. Is this an OpenSSL specific issue?
> >
> > These are partially based on a lack of knowledge of the OpenSSL
> > implementation, so forgive me for any newbie questions there.
> >
> >
> as I said, the SSL_CTX_set_tmp_ecdh is used only for the TLS control
> channel connection. It does *NOT* add elliptic curve support on the
> data channel, as this requires quite a few more changes, some of which
> are not supported by the OpenSSL libs right now (e.g. the fact that
> openvpn calls the signing functions directly).
> 

What I'm mostly concerned with is the control channel setup. As I understand 
it, there's two steps involved that can use elliptic curve crypto:

1. Authentication using ECDSA/RSA/DSA/whatever
2. Anonymous DH/ECDH negotiation to get a session key

What I'm wondering is, if you use ECDSA, how is the curve for ECDSA set? As I 
understand it, this patch only sets the ECDH curve and key, not the 


> The main reason for adding this patch is to allow the use of
> certificates which are generated with ECDH keys and which are signed
> with a SHA2 family hash; without this patch , this is not allowed.
> 

That's what my question boils down to: isn't ECDSA, not ECDH the 
certificate-based part of the algorithm? ECDH is anonymous, isn't it?

> > Finally one more comment: to be accepted into the main branch, this
> > needs manpage and command line documentation.
> >
> >
> very true... but that applies to more patches ;)
> 

Unfortunately true...

I hope that clarifies my concerns a little. Unfortunately, I haven't found a 
good authoritative source for the functionality of SSL_CTX_set_tmp_ecdh. If it 
works in a similar manner to SSL_CTX_set_tmp_rsa, then you would need to use 
SSL_CTX_set_tmp_ecdh_callback instead to generate a new key for every control 
channel (see the ssl_openssl.c code for an example of that).

Kind regards,

Adriaan

Reply via email to