When reviewing the SSL/TLS configuration using Qualys SSL Labs, I've found that the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param was flagged.

Why is the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param considered bad?

  • I had answered here, but I think I'm confusing curve selection and parameter issues. You may get some clue out of tools.ietf.org/html/bcp195 - section 6.4 - which suggests it is because it prevents forward secrecy, but I'm not even sure that is the same issue. Maybe the folks over at crypto.se will know better?
    – crovers
    Jul 17 '17 at 18:37
  • Practically everyone on the Internet who uses ECDHE uses P-256 or P-384, and I can't believe Qualys would criticize that. Are you sure you don't mean key reuse? That's very different. And with OpenSSL they could be confused because if you use a tmp_ecdh callback that returns an EC containing a keypair (not just an EC_GROUP) and don't set option OP_SINGLE_ECDH_USE it will reuse the key. Jul 18 '17 at 6:36
  • @dave_thompson_085 check ssllabs.com/ssltest/… the third last under "protocol details". If the answer would be yes it would be flagged orange.
    – Bob Ortiz
    Jul 18 '17 at 7:15
  • 1
    I think this is just more name confusion. I tried to take this apart in this answer. Jul 18 '17 at 13:45

Note: I'm deliberately ignoring the difference between regular DH and elliptic curve DH. Doesn't matter here.

Just poor phrasing.

"public server param" vs. "Ephemeral DH parameters" vs. "dhparam"

I think this is just poor phrasing/terminology. SSL Labs uses the definition as per RFC to basically tell you "Yo, i received the same pubkey twice! This shouldn't happen!"

SSL Labs uses the terms DH public server param (Ys) and ECDH public server param for this.

And this only makes sense if you know that they're referring to the RFC definition of what makes up the "parameters" and not to the openssl definition of what makes up "dhparams".

RFC definition

As per the TLS 1.2 RFC the params are defined like so:

struct {
    opaque dh_p<1..2^16-1>;
    opaque dh_g<1..2^16-1>;
    opaque dh_Ys<1..2^16-1>;
} ServerDHParams;     /* Ephemeral DH parameters */

So they DO INCLUDE the pubkey (dh_Ys).

OpenSSL definition

But this conflicts with OpenSSL use of the term params which DOES NOT include the pubkey:

$ openssl dhparam 123 -noout -text
Generating DH parameters, 123 bit long safe prime, generator 2
This is going to take a long time
    DH Parameters: (123 bit)
        generator: 2 (0x2)

Only the prime and the generator are including. No PubKey.

Further reading:

(Read part below only if you're bored.)

Long and rambling Sidenote

Sloppy openssl documentation.

The openssl documentation for ephemeral DH seems to have been contaminated from the openssl documentation for ephemeral RSA. eRSA is a thing of the past and no longer supported but it did the same thing that we now use ephemeral DH/ECDH for.

So what does that have to do with DH/ECDH? Well, the documentation for SSL_OP_SINGLE_DH_USE reads like this:

Always create a new key when using temporary/ephemeral DH parameters [...]

But wait a minute! According to the usual openssl terminology the KEY is the ephemeral part of the parameter/key combo. So why do they even use a term such as temporary/ephemeral DH parameters. -- Well, I think they just copied that from the documentation for the (now dead and buried) eRSA.

So while THIS made sense to say for eRSA:

/* Generating a key on the fly is very costly, so use what is there */
if (rsa_1024)

It does NOT make sense to copy that to the documentation for eDH:

/* Generating a key on the fly is very costly, so use what is there */

This is copied verbatim from the old eRSA example. And in the DH context this does NOT make sense. What is costly is not so much to regenerate the DH-KEY but regenerate the DH-GROUP.

Edit 2017-07-23Sun: Removed wrong "you can share your modulus, no problem" statement.

  • 1
    The difference between DH/ECDH (also DSA/ECDSA) and RSA, ephemeral or not, is that in RSA each key stands alone while DH/DSA and ECDH/ECDSA first define parameters (for DH/DSA p,g,q where the q can be dropped for DH, or for ECDH/ECDSA an elliptic curve over a finite field and base point and order and cofactor but we generally use standardized 'named' parameter sets misdescribed as 'curves' like P-256) which can be longterm (and must for named curves) and then generates multiple keys within that set of parameters. Otherwise concur especially with your link. Jul 19 '17 at 1:08
  • @dave_thompson_085: Appreciate the feedback. I tried to argue the same thing: (EC)DH uses a group that you can reuse with multiple keys and eRSA also uses that group that you could reuse with multiple keys. But in practice you use 0x10001 for the pubkey and therefore have no choice but to regenerate the whole caboodle. Group (i.e. modulus) included. Jul 21 '17 at 8:08
  • I'm not sure what you mean. If you mean reusing an RSA modulus n with different d,e pairs, that's prohibited because an adversary can immediately break it. If you mean reusing one prime p or q, ditto. (I've seen Qs here or crypto on both.) Every RSA key must have its own modulus, so that can't be a shared parameter. Fixing e to a convenient value like 3 or F4 could be considered a parameter but it isn't defined or encoded as one, and it decidedly isn't a group. Jul 23 '17 at 9:56
  • @dave_thompson_085: I meant the first one. I guess I will have to read up on the common modulus attack and rephrase my answer. Jul 23 '17 at 12:57
  • If you didn't generate the key yourself you can't be sure it's not with a back-door

  • If a key is shared with enough servers, it became more attractive, more cost-efficient to crack it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.