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

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

• Every number generated is deleted after one use, making it ephemeral. Both a and b are wiped instantly after authentication, and the shared key is wiped after the session, and the seeds for those numbers are also wiped instantly. What makes it practically secure is that signatures are used to authenticate it by signing the public unique random parameters with known public keys that are more static. That way you know you now share a key with the key holder for public key XYZ. Nov 19 '15 at 22:41
• Given this definition, @natanael, why would a non-ephemeral DH ever have been implemented? Generating a random `a` and doing modular exponentiation with a known `p,g` is a straightforward operation… do "non-ephemeral" DH protocols really just reuse the same `A`/`B` over and over and over!? Jul 21 '18 at 14:08

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.

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.

# Citrix NetScaler I'm not sure.

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.

• Nice scour of the web's use of ephemeral. The "Handbook of Applied Cryptography" defines ephemeral secret as one whose use is restricted to a short time period such as a single telecommunications connection (or session), after which all trace of it is eliminated. TLS 1.2 (RFC 5246) does appear to allow signed, pre-computed (i.e. non-ephemeral) g^Y%P. That gives me the security willies. One thought about crowd-sourced definitions: many developers call this irreversible step `SHA(pwd)` password encryption. This misuse shows poor cryptography fu; don't always trust the crowd. Nov 20 '15 at 14:39
• FYI: The F5 BIG-IP Single DH function helps defeat some logjam attack vectors and was referenced in the logjam whitepaper. devcentral.f5.com/articles/…
– user89449
Nov 20 '15 at 17:41
• I tried to dig into F5 DH algorithm to see what they do and don't regenerate, i.e. what they consider ephemeral. I couldn't find any information, but perhaps I didn't use the right search terms. The Logjam defeat mentioned was more about improved configuration related to not falling back to weaker (export level) ciphers and faster timeouts on export level ciphers than the strength and expiry of the <g,P,Y> terms. It would be great to know what they do with these, as that really is the other half of the problem. Nov 20 '15 at 22:59
• @AndrewPhilips all versions SSLv3 to TLSv1.2 define 'static' aka 'fixed' DH, but it can only be used if you have a certificate for a DH key, which no public CA will issue; it isn't even possible to form a PKCS#10 CSR for a DH key. OpenSSL didn't implement static-DH ciphersuites for the past 15+ years and apparently no one complained, see crypto.stackexchange.com/questions/19452/… . rfc4492 similarly defines static ECDH, which I have seen browsers/clients accepting -- but is that worse than plain-no-PFS RSA? Nov 21 '15 at 3:00