In Ephemeral Diffie Hellman Key Exchange - what is actually ephemeral?

Question

Just starting to learn about Diffie-Hellman, and it seems simple enough, but I am struggling to find any resources that explain in an Ephemeral Diffie Hellman Key Exchange, what it is that is actually ephemeral?

So in DH we have a publicly known prime p, and a g mod p over the cyclic multiplicative group, where g is a generator of the group.

1. Alice chooses a random a, Bob choose a random b, both mod p.
2. Alice computes A = g^a mod p
3. Bob computes B = g^b mod p
4. Bob transfers B to Alice
5. Alice transfers A to Bob.
6. Alice computes B^a mod p
7. Bob computes A^b mod p
8. Both of these computations result in the same answer,and therefore a shared key has been established.

In ephemeral Diffie Hellman, what exactly is ephemeral? Do p and g change? Are a and b recomputed periodically?

Thanks

Answer 1

A & B are called the ephemerals that Alice and Bob exchange. It's not more complicated than that. There are other ways to use Diffie Hellman, for example DSA - Digital Signing Algorithm in which the term ephemeral does not appear.

Also, usually, (P,g) are fixed not only for a website, but for much of the internet (via RFCs) which is related to the recent revelation about the Logjam attacks and NSA likely hackings. Here's my write up on that. In any event, (P,g) are complicated to create, so most people use the ones that are already out there. Therefore, they don't change much. Given the recent exposures, it looks like we need to use bigger ones or you can compute your own (should be a big P).

(a,b) are not recomputed periodically except by policy for some network security protocol or, in the case of TLS, cipher suite configuration. I'm not familiar enough with TLS cipher suite config to answer that question. Generally, for improved security a network session should recompute session keys on a periodic basis. This is usually 8 hours, although it can be shorter or longer. Nothing in math requires the recomputation, it's only advised.

Answer 2

Here's my shot. I'm not completely happy with it. I'd appreciate criticism.

At least pubkey/privkey. Sometimes params.

I don't think this is nicely defined. But I have NO sources to back this up. (If someone can show me a standards document I'd be pleased to be shown wrong. Anything is better than uncertainty there for me.)

The TLS1.2 RFC says that the server gets to pick these three:

  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 the server COULD change ANY of the three.

But I think that actually only the server's pubkey (dh_Ys) will change. And this should be enough to give forward secrecy.

But only if your

  opaque dh_p<1..2^16-1>;
  opaque dh_g<1..2^16-1>;

are unlikely to be broken anytime soon. (Like if they are 2048 bits.) (And Thomas Pornin said on a different question: To get bad DH parameters, you have to do it on purpose.)

F5's "Single DH use"

Now I've looked at F5's website to find out how their load balancers implement EDH.

And they have an option called Single DH use which I think regenerates the dh_p/dh_g pair.

Here's the quote. I don't understand why I would want that. Confuses me.

Single DH use

This option creates a new key when using temporary/ephemeral DH parameters. You must use this option if you want to prevent small subgroup attacks, when the DH parameters were not generated using strong primes (for example, when using DSA-parameters). If strong primes were used, it is not strictly necessary to generate a new DH key during each handshake, but we do recommend this. You should enable the Single DH use option whenever temporary/ephemeral DH parameters are used.

F5 Keys generated hourly

F5 has an article that says Beginning in BIG-IP 11.4.0, the generation of new ephemeral keys occurs hourly.

I suspect they are using "keys" and "parameters" interchangably.

CryptoPP calls the "regenerated keypair" method ephemeral.

When CryptoPP talks about EDH they mean: group stays the same. Keypair changes.

Citrix NetScaler I'm not sure.

Again, I'm not sure if they completely differentiate between dhparams and dh-keypair.

dhFile

Name for and, optionally, path to the PEM-format DH parameter file to be installed. /nsconfig/ssl/ is the default path.

This parameter is not applicable when configuring a backend profile.

dhCount

Number of interactions, between the client and the NetScaler appliance, after which the DH private-public pair is regenerated. A value of zero (0) specifies infinite use (no refresh).

This parameter is not applicable when configuring a backend profile.

Minimum value: 0

Maximum value: 65534

dhKeyExpSizeLimit

This option enables the use of NIST recommended (NIST Special Publication 800-56A) bit size for private-key size. For example, for DH params of size 2048bit, the private-key size recommended is 224bits. This is rounded-up to 256bits.

Possible values: ENABLED, DISABLED

Default value: DISABLED

Here dhKeyExpSizeLimit confuses me. I don't understand why you would allow that part to be user-definable.