# Introduction to the Diffie-Hellman key exchange

Published:

Updated:

The Diffie-Hellman (DH) key exchange (and variants thereof) is widely used in many protocols (such as TLS, SSH, IKE (IPSec), Signal, etc.) to bootstrap some symmetric key material which may then be used to secure communication channel between two parties. This introduction focuses on the different ways the DH key exchange is used in practice in several protocols (especially TLS) and the impact of these different approaches on the security. This is intended as a prelude for the upcoming next episodes about how TLS works.

**Prerequisites:** public key vs. private key vs. secret key key, encryption, MAC, digital signature, cryptographic hash.

**Concepts introduced:** Diffie-Hellman key exchange, anonymous vs. authenticated Diffie-Hellman key exchange, ephemeral vs. static Diffie-Hellman key pairs/exchange, triple Diffie-Hellman key exchange (3DH), forward secrecy, key compromise impersonation (KCI), identity misbinding attack.

After a quick overview, we will present the unauthenticated DH key exchange. The downside of the unauthenticated DH key exchange is that the parties have no assurance that they are actually communicating with the intended party: this approach only protects against passive eavesdroppers but not against active attackers. and it is therefore usually desirable to authenticate at least one participant. We will see several approaches to integrating some authentication (for either or both parties) in the key exchange:

- one party may be authenticated using a static DH key pair bound to its identity;
- one party may be authenticated by including a digital signature in the key exchange;
- both parties may be
*mutually authenticated*by including a shared secret in the key exchange.

Disclaimer: don't roll your own crypto!

I'm not an expert in cryptography. This post is not supposed to teach you how to implement secure cryptographic protocols: *do not roll your own crypto*; use an existing implementation of a well-known protocol (eg. TLS) if you can.

## Table of Content

- Table of Content
- Overview
- Unauthenticated Diffie-Hellman key exchange
- Authenticating the Diffie-Hellman key exchange using a static Diffie-Hellman key
- Authenticating Diffie-Hellman key exchange using digital signature
- Authenticating the Diffie-Hellman key exchange using a shared secret
- Conclusion
- Appendix, encryption using Diffie-Hellman
- Appendix, mathematical considerations
- References

## Overview

### Motivation

Let us assume that Alice and Bob want to communicate over the network. They would like to protecte themselves from eavesdroppers (Eve^{[1]}) listening to their communications (confidentiality) and active attackers (Mallory^{[2]}) tampering with their communications (data integrity). They could use encryption and Message Authentication Codes (MACs) in order to provide confidentiality and data integrity^{[3]} respectively. In order to do that, they need to agree on some shared keys to use (for the encryption and/or MAC).

Obviously, Alice cannot simply send these shared keys to Bob in clear text over the network: these secrets keys would not be secret at all. An attacker could eavesdrop them and use them to decrypt the communications or tamper with them. Instead, Alice and Bob would need a method to agree on some shared keys without sending these keys (or any other informations which could be used to compute them) in clear text over the network.

### Summary

The Diffie-Hellman key agreement is a method for two parties to agree on a shared secret without revealing this shared secret to eavesdroppers.

**How?** The two parties exchange Diffie-Hellman public keys and each party then uses its own Diffie-Hellman private key with the other party Diffie-Hellman public key to compute the *same* shared secret (the **Diffie-Hellman shared secret**). This shared secret is not revealed to eavesdroppers because even though the eavesdropper can observe the DH public keys, he does not know any of the two DH private keys: he therefore cannot compute the DH shared secret.

The following diagram gives an idea about how this works. Some details on these computations are given in appendix.

**Why?** The two parties can use this shared secret to secure some communication by deriving^{[4]} some symmetric key material from the shared secret.

Note: key material

The key material derived from the DH shared secret would typically include:

- two encryption secret keys (one for each direction) to encrypt the messages (confidentiality);
- two MAC secret keys (one for each direction) to authenticate the messages, if the cipher used does not already provide data integrity;
- initialization vectors (IV), if needed.

Note: FFDH and ECDH

The DH key agreement can be conducted using different types of mathematical objects (groups. For example,

- Finite Field Diffie-Hellman (FFDH) uses finite fields;
- Elliptic-Curve Diffie-Hellman (ECDH) uses elliptic curves.

Everything discussed here applies to both FFDH and ECDH.

The original/classical Diffie-Hellman formulation is FFDH which was known as “Diffie-Hellman” at this point. Therefore, term “DH” is often used to refer to FFDH as opposed to ECDH. For example, in TLS v1.2 and below the `TLS_DH(E)_*`

cipher suites use FFDH whereas the `TLS_ECDH(E)_*`

cipher suites use ECDH.

Examples of usage

Many protocols use the Diffie-Hellman key exchange:

## Unauthenticated Diffie-Hellman key exchange

The unauthenticated (anonymous) Diffie-Hellman key exchange uses **ephemeral DH key pairs** for each party: each party generates a new Diffie-Hellman (public/private) key pair for each Diffie-Hellman key exchange. This is called **ephemeral-ephemeral** Diffie-Hellman.

Note: static vs. ephemeral Diffie-Hellman key

**Ephemeral DH key:** when the party generates a new DH key pair for each key exchange.

**Static DH key:** when the party reuses the same DH key pair for all key exchanges.

**Ephemeral-ephemeral DH (DHE):** both parties use ephemeral DH key pairs.

**Ephemeral-static DH (DHES):** one party uses ephemeral DH key pairs and the other party a static DH key pair.

**Static-static DH:** each party uses its (own) static DH key pair.

Explanation:

- each party generates a fresh (ephemeral) DH key pair;
- the two parties exchange their ephemeral DH public keys;
- each party uses its ephemeral DH private key and the other party DH public key to compute the same shared secret (the DH shared secret);
- this shared secret can be used to derive
^{[4:1]}key material in order to establish a secure communication channel.

Each party can compute the same shared secret using its private DH key and the other party public DH key:

shared_secret_between_alice_and_bob = DH(alice_private_key, bob_public_key) = DH(bob_private_key, alice_public_key)

A passive attacker, only knows the DH public keys but not the DH private keys: he cannot compute the DH shared secret and the key material.

Note: key confirmation

It is often necessary to include some key confirmation mechanism after the key agreement. See for example, the `Finished`

messages in TLS v1.2 and v1.3.

Warning: vulnerable to active attack (unauthenticated)

One major downside of using an unauthenticated DH key exchange is that it is vulnerable to active attacks. As the exchange is not authenticated, one participant cannot be sure that the party he has been conducting a DH key agreement with is the one he is really intending to communicate with. By intercepting the key exchange, an active attacker may impersonate one party, intercept the communications, etc.

In the following sections, we will cover how to authenticate a Diffie-Hellman key exchange using some long-term secret. This may be a static DH private key, a signing private key, a pre-shared key (PSK) or a passphrase.

Warning: don't use encryption without message authentication

You really want to use some form of message authentication in addition to encryption. This can be done either by using an AEAD (which already integrates message authentication in addition to encryption) or by including a MAC in addition to the encryption scheme you are using.

Example: usage in TLS v1.2

The anonymous TLS cipher suites use this approach. These are the cipher suites containing `DH_anon`

or `ECDH_anon`

(such as `TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384 `

or `TLS_ECDH_anon_WITH_AES_128_CBC_SHA`

). The DH public keys are exchanged in the `ServerKeyExchange`

and `ClientKeyExchange`

messages.

The server is *not* authenticated when using these cipher suites.

Example: usage for opportunistic encryption in Wifi (OWE)

Wifi OWE (Opportunistic Wireless Encryption) uses an unauthenticated Diffie-Hellman key exchange to provide opportunistic encryption (protection against passive attacks) to open Wifi networks. OWE is designed to be used as a (more secure) replacement for unencrypted open Wifi.

In OWE, the station and the access point (AP) exchange ephemeral DH public keys in the 802.11 association request and association response messages respectively. They then derive key material from the resulting DH shared secret.

## Authenticating the Diffie-Hellman key exchange using a static Diffie-Hellman key

### One-way authentication using ephemeral-static Diffie-Hellman key exchange

A party (here Bob) can authenticate itself by using a static DH key pair bound to its identity.

Note: key distribution

For this to work, Alice somehow need to learn Bob's (static) DH public key. This may for example be:

- through prior out-of-band provisioning;
- through a certificate issued by a trusted certificate authority (CA);
- using trust-on-first-use (TOFU), aka leap-of-faith.

If only one party is authenticated this way, the other party uses an ephemeral DH key pair: this is **ephemeral-static** Diffie-Hellman (DHES). If each party uses a (different) static DH key pair, this is **static-static** Diffie-Hellman (discussed below).

Warning: lack of forward secrecy

If an attacker manages to get the static DH private key of one party, he can compute the DH shared secrets of all key exchanges which were using that static DH private key and decrypt the associated communications: static DH key exchanges do not provide **forward secrecy** with respect to the static DH private key.

This is why the usage of static DH key exchanges is now discouraged in TLS. Static DH key exchanges have been completely removed in TLS v1.3.

### Replay Attack on static Diffie-Hellman key exchange

In the previous diagram, an attacker could make a replay attack on the party using the static DH key pair.

This can be fixed by having this party send a random nonce and including this nonce to derive a secret key.

Example: usage of static Diffie-Hellman keys in TLS v1.2

The TLS `DH_DSS`

, `DH_RSA`

, `ECDH_ECDSA`

and `ECDH_RSA`

key exchange methods (for example in `TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA`

) use this approach for authenticating the server.

- the client and the server exchange random nonces in the
`ClientHello`

and`ServerHello`

messages; - the client and server exchange DH public keys in the
`ServerKeyExchange`

; - they then derive a master secret from the random nonces and the DH shared secret.

TLS client authentication uses this approach as well when used with the `rsa_fixed_dh`

, `dss_fixed_dh`

, `ECDSA_fixed_ECDH`

, `RSA_fixed_ECDH`

certiticate types.

Using either of these method for authentication do not provide forward secrecy with respect to the static DH private key.

When both the client and server key are static, we have static-static Diffie-Hellman (see below).

### Mutual authentication using static-static Diffie-Hellman key exchange

If each party uses a static a DH key pair, we get **static-static** Diffie-Hellman. In this case, the DH shared secret is always the same between the two parties. However, we don't want to reuse the same key material as the result of different key exchanges between the same pair of parties. In order prevent this, the parties can exchange nonces; then, they derive the key material from the DH shared secret and the nonces.

Warning: lack of forward secrecy

This does not provide forward secrecy with respect to any of the static DH private keys. If an attacker compromises any of the static DH private keys, she can then use this key to decrypt previous communications which were using that key.

Warning: key compromise impersonation (KCI)

In all these key exchange authentication methods, Alice authenticates herself using some authentication secret (either a static DH private key, a signing private key, a PSK or a passphrase). If an attacker manages to obtain Alice's authentication secret, this attacker can impersonate *Alice*.

In static-static DH^{[5]}, if the attacker manages to get Alice's private DH key, he can in addition impersonate *anyone else when they are talking to Alice*. This vulnerability is called Key Compromise Impersonation (KCI).

See KCI Attacks against TLS for a practical application in TLS.

### Mutual authentication using a triple Diffie-Hellman

Another solution to provide mutual authentication is to use a triple Diffie-Hellman (3DH)^{[6]} key agreement. Each participant uses both a static DH key pair and an ephemeral DH key pair. They combine the DH shared secrets resulting from three DH key agreements:

- one ephemeral-static DH key agreement using Alice's static key pair and Bob's ephemeral key pair which authenticates Alice;
- one ephemeral-static DH key agreement using Bob's static key pair and Alice's ephemeral key pair which authenticates Bob;
- one ephemeral-ephemeral DH key agreement using both participants' ephemeral key pairs which provides forward secrecy
^{[7]}.

Note: not vulnerable to KCI with respect to the static DH key pairs

An attacker having access to Alice's private static DH key cannot use it to compute the DH shared secret resulting from Alice ephemeral DH key pair and Bob static DH key pair. Therefore, this approach is not vulnerable to KCI with respect to the party static DH private key.

Example: X3DH, Signal, etc.

The Extended Triple Diffie-Hellman (X3DH) is an extensions of this approach. X3DH is used by the Signal protocol. The Signal protocol is used by Signal, What's App, etc.

## Authenticating Diffie-Hellman key exchange using digital signature

Instead of using static DH key pairs, we can use digital signatures to authenticate the DH key exchange.

### Badly authenticated Diffie-Hellman

One simple (but broken) solution would be for each party to sign either its own ephemeral DH public key or the two DH public keys.

Note: freshness

In this diagram, each party signs both its own ephemeral DH public key (for authentication) and the other party ephemeral DH public key (for freshness). Including the other party ephemeral DH public key (or nonce contributed by the party) guarantees the freshness of the signature to the other party.

However, this approach is vulnerable to **identity misbinding attacks**. If Alice tries to established a mutually authenticated communications with Charlie and if Charlie is malicious (for example because it has been compromised), Charlie can trick Alice into establishing a communication with Bob instead:

- from the point of view of Alice, a mutually authenticated communication happens between Alice and Charlie;
- from the point of view of Bob, a mutually authenticated communication happens between Alice and Bob.

This attack is possible because the attacker (Charlie) is able to manipulate the handshake messages without being detected.

### Correctly authenticated Diffie-Hellman

Several approaches can be used to prevent this type of manipulations from getting unnoticed:

- in the ISO/IEC IS 9798-3 key exchange protocol, the digital signature covers both ephemeral DH public keys and the recipient identity;
- in SIGMA (Sign-and-MAC), each party sends a MAC of its own identity as well (using a secret key derived from the DH shared secret);
- in TLS v1.2 and v1.3, each party sends (in the
`Finished`

messages) a MAC of the previous handshake messages (which includes the identity of the authenticated parties in the`Certificate`

messages).

Example: usage in TLS v1.2 for server authentication

In TLS v1.2, the *server* authenticates itself using digital signatures when using the `TLS_(EC)DHE_*`

cipher suites (for example `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`

):

- the
`ServerKeyExchange`

message contains a signature of the server ephemeral DH public key the server and client nonces; - the server
`Finished`

message contains a MAC of the previous messages.

Example: usage in TLS v1.2 for client authentication

In TLS v1.2, the *client* authenticates itself using digital signature when it uses the `rsa_sign`

, `dss_sign`

or `ecdsa_sign`

certificate type:

- the client
`CertificateVerify`

message contains a signature of previous handshake messages; - the client
`Finished`

message contains a MAC of previous handshake messages.

Example: usage in TLS v1.3

In TLS v1.3 (without PSK), both client and server authentication use a digital signature:

`CertificateVerify`

message contains a signature of the hash of the previous handshake messages;- the
`Finished`

message contains a MAC of previous handshake messages.

Note: forward secrecy

This approach provides forward secrecy (with respect to the signing private keys). By getting access to one party's signing private key, an attacker could of course impersonate this party in subsequent key exchanges. However, having the signing private key would not enable the attacker to recover the DH shared secrets (and the key materials) of previous key exchanges which were authenticated using that key.

Warning: the ephemeral key may not actually be ephemeral

A party could (unilaterally) decide to use a static DH key pair in what is expected to be an ephemeral DH key exchange. This might be for granting access to the plain text to a third party or for computational efficiency reasons. In this case, the key exchange does not provide the expected forward secrecy with respect to this long-lived key^{[8]}.

## Authenticating the Diffie-Hellman key exchange using a shared secret

### Authenticating the Diffie-Hellman key exchange using a pre-shared key

We can combine ephemeral-ephemeral Diffie-Hellman with some other secret shared, the pre-shared key (PSK), between the client and the server:

- the PSK is used to provide
*mutual*authentication; - ephemeral-ephemeral DH is used to provide forward secrecy with respect to the PSK.

Example: usage in TLS v1.3

In TLS v1.3, the `psk_dhe_ke`

key exchange mode (i.e. PSK with (EC)DHE) uses this approach.

Warning: low-entropy secret

This method should be used with high entropy PSKs (such as random PSKs). It should not be used for PSKs derived from passwords.

### Authenticating the Diffie-Hellman key echange using a password

Other key exchanges based on Diffie-Hellman are designed to be used with low-entropy shared secrets (such as secrets derived from a password).

Examples of authenticating the Diffie-Hellman with a password

For example this approach is used in:

- Password-Authenticated Key (PAK) Diffie-Hellman Exchange;
- SPEKE (Simple Password Exponential Key Exchange);
- Dragonfly;
- EAP-PWD, EAP Authentication Using Only a Password;
- WPA3-personal aka WPA-SAE (Simultaneous Authentication of Equals), based on Dragonfly;
- SRP (Secure Remote Password) and TLS-SRP;
- TLS-PWD, based on Dragonfly.

Example: Diffie-Hellman in WPA-SAE

In WPA2-personal (WPA2-PSK), the key exchange does not use a Diffie-Hellman key agreement. Both the station and the AP derive a PSK from the passphrase of the Wifi network^{[9]}. Then, they combine this PSK with the exchanged nonces to derive the key material. Anyone who knows the PSK can compute the encryptions secret keys of previous handshakes (assuming he has observed the nonces) and decrypt the associated Wifi traffic. Therefore, WPA2-personal does not provide forward secrecy with respect to the passphrase/PSK. In WPA-personal, all users of the Wifi network usually^{[10]} share the same secret password: any of those users can use the shared secret to passively decrypt the traffic of other stations (including previous communications).

WPA3-personal improves this by using WPA-SAE (Simultaneous Authentication of Equals). This combines an ephemeral-ephemeral DH key exchange with the PSK in order to provide forward secrecy with respect to the passphrase/PSK. A passive attacker having access to the PSK cannot decrypt the traffic.

In both cases, an active attacker having access to the passphrase/PSK can impersonate the access point (or join the network and try to use layer 2 attacks such as ARP poisoning, ICMP redirection, etc.).

## Conclusion

We have seen how the DH key agreement can be used to generate key material between two parties.

It is usually desirable to **authenticate** either or both parties in order to protect against active attacks. Each party may be authenticated for example by:

- including a DH static key pair associated with the party's identity in the key exchange;
- including a digital signature of the key exchange.

Alternatively, **mutual authentication** may be achieved by including some shared secret in the key exchange.

**Forward secrecy** can be achieved by including an ephemeral-ephemeral DH key agreement in the key exchange.

Each party can be protected against **replay attacks** by contributing some ephemeral value to the key exchange:

- either an ephemeral DH key pair;
- or a random nonce which is included in the key derivation.

## Appendix, encryption using Diffie-Hellman

The Diffie-Hellman key exchange protocol can be used for hybrid public-key encryption: both the Elgamal encryption (not discussed here) and the Diffie-Hellman Integrated Encryption Scheme (DHIES) are based on DH. In this context, the receiver cannot contribute any ephemeral value (which could be used to provide forward secrecy and anti-replay protection).

Examples

Several encryption standards have support for encryption based on the Diffie-Hellman key exchange: JWE/JWA, XML encryption, CMS, OpenPGP, etc.

The HPKE public-key encryption scheme uses this approach as well. HPKE is expected to be used in the Encrypted Client Hello (ECH) extension for encrypting the TLS ClientHello message.

### Diffie-Hellman Integrated Encryption Scheme

In DHES-based encryption, the sender generates an ephemeral DH key pair and derives a DH shared-secret with the recipient static DH public pair. It then derives some key material from this shared secret which might either be:

- a (secret)
**content encryption key**(CEK) used to directly encrypt (and authenticate) the data (**direct key agreement**); - a (secret)
**key encryption key**(KEK) used to encrypt a CEK (**key agreement with key wrapping**).

Example: DHIES, DLIES and ECIES

Diffie-Hellman Integrated Encryption Scheme (DHIES) uses the direct approach.

The sender:

- generates an ephemeral DH keypair;
- computes a DHES shared secret from its ephemeral DH private key and the recipient's static DH public key;
- derives both a encryption secret key and a MAC key from this DHES shared secret;
- encrypt-then-MAC the message using these secret keys.

Discrete Logarithm Integrated Encryption Scheme (DLIES) is DHIES using FFDH. Elliptic Curve Integrated Encryption Scheme (ECIES) is DHIES using ECDH.

Example: DHES encryption in JSON Web Encryption (JWE)

- direct mode (
`ECDH-ES`

); - key wrapping mode (
`ECDH-ES+A128KW`

,`ECDH-ES+A192KW`

and`ECDH-ES+A256KW`

).

Example: DHES in HPKE base mode

The HPKE base mode with a DH-based key encapsulation method (DHKEM) uses a similar (direct) approach.

The sender:

- generates an ephemeral DH keypair (
`skE, pkE`

); - computes the DH shared secret (
`dh`

) from its ephemeral DH private key and the recipient's static DH public key; - derives (using HKDF) another shared secret (
`shared_secret`

) from the DH shared secret and*both*DH public keys; - derives (using HKDF) a secret key (
`key`

) and a base nonce (`base_nonce`

) for an AEAD from this second shared secret; - encrypts (AEAD) the payload (possibly with additional authenticated data) using the secret key and nonce derived (
`self.ComputeNonce(...)`

) from the base nonce; - sends the ephemeral DH public key and the ciphertext (
`ct`

) to the recipient.

See `Encap()`

, `SetupBaseS()`

, `KeySchedule<ROLE>()`

, `ContextS.Seal()`

and `Seal<MODE>()`

.

### Encryption based on static-static Diffie-Hellman

If both the sender and the receiver use static DH keys, the sender is authenticated as well (assuming that authenticated encryption is used). A nonce must be included in this case: otherwise the key material would always be the same between the same two parties.

Another advantage of this approach is that the sender can decrypt the message as well.

Note: non-repudiation vs. repudiability

This approach provides **repudiability** The receiver cannot prove to a third party that the sender actually created the message: the message could have been forged by the receiver. In contrast, authenticating the sender by sign-then-encrypting the plaintext message would provide **non-repudiation**.

Either non-repudiation or repudiability could be desirable depending on the application:

- non-repudiation might be desirable for public communications, contracts, certificates such as X.509/PKIX certificates, X.509 certificate revocation lists (CRLs), COVID-19 certificates, etc.
- repudiability might arguably be desirable for private communications.

See for example the OTR paper:

In this paper, we examine what kind of privacy is necessary for social communications. We argue that not only must encryption be used to hide the contents of the conversation, but also, the encryption must provide perfect forward secrecy to protect from future compromises. Additionally, authentication must be used to ensure that the person on the other end is who they claim to be. However, the authentication mechanism must offer repudiation, so that the communications remain personal and unverifiable to third parties. Only with these properties can privacy similar to real-world social communications be achieved.

Warning: Key Compromise Impersonation

As before, if an attacker manages to compromise the static DH private key of Alice, it can then use this key to impersonate every other party (Bob) when talking to Alice.

### Combining static-static and ephemeral-static Diffie-Hellman

The HPKE scheme in authenticated mode with DHKEM uses a similar approach to provide public-key authenticated encryption. Instead of using a nonce, the sender combines a static-static DH key agreement and a DHES key agreement:

- the static-static DH key agreement uses the sender's static DH key and the recipient's static DH key;
- the DHES key agreement uses a sender's ephemeral DH key and the recipient's static DH key.

The sender and the receiver both derive the key material from both DH shared secrets and the three DH public keys.

Warning: Key Compromise Impersonation

This approach is vulnerable to KCI as well.

## Appendix, mathematical considerations

### Diffie-Hellman parameters

The two parties first agree on a finite cyclic group (𝒢, +) to use for the Diffie-Hellman exchange and a generator g ∈ 𝒢 of this group. The choice of these two parameters may be hardcoded in the protocol/implementation/configuration or could be negotiated in some way.

Let n the order of the group, we have |𝒢| = n and 𝒢 = { i.g : i ∈ {0, …, n - 1} }. In other words, the function f(i) = i.g is a bijection from {0, …, n - 1} (or equivalently ℤ/nℤ) to 𝒢.

Note: notations (additive group vs. multiplicative group)

In this post, we are considering the group as an additive group (𝒢, +). Many papers use the multiplicative notation (𝒢, .) instead: this is purely a difference in the notation. I am using the additive notation because I find the notation more convenient. You will find a summary of the two notations in the table below.

### Key generation

**Summary:**

- a private DH key is an element of {0, …, n - 1};
- a public DH key is an element of 𝒢;
- the generator g defines the mapping from the private key set {0, …, n - 1} to the public key set (𝒢).

For generating a DH private key, a party chooses a random integer 1 < ka < n: this value is the private key. The associated DH public key is the corresponding element of 𝒢: Ka = ka.g ∈ 𝒢.

This is only interesting if we are working in a 𝒢 where computing the private key ka from the public key Ka (discrete logarithm problem) is not tractable. One necessary conditions is for n to be large enough for a brute-force approach to be intractable.

### Key agreement

Once two parties Alice and Bob have exchanged their DH public keys Ka and Kb, they can compute the *same* DH shared secret z:

- for Alice, it is computed as z = ka . Kb ∈ 𝒢;
- for Bob, it is computed as z = kb . Ka ∈ 𝒢.

The two parties compute the same value because ka . Kb = ka . kb . g = kb . ka . g = kb . Ka.

An attacker knows Ka and Kb but not ka and kb and cannot reproduce any of these two computations. In order to compute the DH shared secret z, the attacker has to solve the Computational Diffie-Hellman problem. One way to solve this problem would be to solve the discrete logarithm problem. Moreover, solving the Computational Diffie-Hellman problem is equivalent to the discrete logarithm problem for many classes of groups.

### Summary

Additive group | Multiplicative group | |
---|---|---|

Group | (𝒢, +) | (𝒢, .) |

Group operation | x + y ∈ 𝒢 | x . y ∈ 𝒢 |

Group exponentiation | i . x = x + … + x ∈ 𝒢 (i times) | x^{i} = x . … . x ∈ 𝒢 (i times) |

Generator (g ∈ 𝒢) | 𝒢 = { i.g : i ∈ {0, …, n - 1} } | 𝒢 = { g^{i} : i ∈ {0, …, n - 1} }. |

DH private key | 1 < ka < n | 1 < ka < n |

DH public key | Ka = ka.g ∈ 𝒢 | Ka = g^{ka} ∈ 𝒢 |

DH shared secret | z = kb . Ka = ka . Kb = ka . kb . g ∈ 𝒢 | z = Ka^{kb} = Kb^{ka} = g^{ka.kb} ∈ 𝒢 |

Discrete Logarithm problem | Given k.g ∈ 𝒢, find k ∈ {0, …, n - 1} | Given g^{k}, find k ∈ {0, …, n - 1} |

Computational DH problem | Given g ∈ 𝒢, k.g ∈ 𝒢 and k'.g ∈ 𝒢, find k.k'.g. | Given g ∈ 𝒢, g^{k} ∈ 𝒢 and g^{k'} ∈ 𝒢, find g^{k.k'} |

Where n is the order of the group. ∀x ∈ 𝒢, ∀y ∈ 𝒢, ∀i ∈ ℤ.

## References

- RFC2631, Diffie-Hellman Key Agreement Method
- RFC5683, Password-Authenticated Key (PAK) Diffie-Hellman Exchange
- RFC7664, Dragonfly
- RFC6637, ECC in OpenPGP
- RFC5246, TLS v1.2
- RFC8446, TLS v1.3
- RFC6347, DTLS v1.2
- RFC4253, SSHv2 transport layer
- RFC5656, ECC in SSHv2 (ECDH, ECMQV and ECDSA)
- RFC8731, Curve25519 and Curve448 for SSHv2
- RFC8110, Wifi OWE (Opportunistic Wireless Encryption)
- RFC5931, EAP-PWD
- RFC8492, TLS-PWD
- RFC4306, IKEv2
- RFC4492, ECC in TLS (ECDH, ECDHE and ECDSA)
- RFC7435, Opportunistic Security
- RFC5054, TLS-SRP (Secure Remote Password)
- RFC5116, An Interface and Algorithms for Authenticated Encryption
- RFC7516, JWE (JSON Web Encryption)
- RFC7518, JWA (JSON Web Algorithms)
- RFC3370, CMS algorithms
- RFC6278, Static-Static ECDH in CMS
- Draft for HPKE, Hybdrid Public Key Encryption
- Draft for ECH, Encrypted Client Hello
- XML encryption
- NIST Special Publication 800-56A R2 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
- NIST Special Publication 800-56A R3 - Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
- Off-the-Record (OTR), Nikita Borisov et al
- The Noise Protocol Framework, Trevor Perrin
- WireGuard: Next Generation Kernel Network Tunnel, Jason A. Donenfeld
- Signal - The Double Ratchet Algorithm, Trevor Perrin, Moxie Marlinspike
- Signal - The X3DH Key Agreement Protocol (triple Diffie-Hellman), Moxie Marlinspike, Trevor Perrin
- Supersingular isogeny Diffie–Hellman (SIDH), Luca De Feo et al
- Cryptanalysis of the Dragonfly Key ExchangeProtoco, Dylan Clarke and Feng Hao
- On the Security of the SPEKE Password-Authenticated Key Exchange Protocol, Philip MacKenzie
- On the Provable Security of the Dragonfly Protocol, Jean Lancrenon, Marjan Škrobot
- On reusing ephemeral keys in Diffie-Hellman key agreement protocols, Alfred Menezes and Berkant Ustaoglu
- Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses, Jee Hea An
- SoK: Secure Messaging, Nik Unger and Sergej Dechand
- Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3, Marc Fischlin et al
- Authentication in Key-Exchange: Definitions, Relations and Composition, Cyprien Delpech de Saint Guilhem et al
- SIGMA: the ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols, Hugo Krawczyk
- Authentication and Authenticated Key Exchanges, Whitfield Diffie
- Modular Security Proofs for Key Agreement Protocols, Caroline Kudla, Kenneth G. Paterson
- Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, David Adrian et al

Backlinks:

Eve is traditionally used to designate an eavesdropper (a passive attacker). This type of attacker is able to see the message on the network but cannot modify, send or intercept messages. ↩︎

Mallory is traditionally used to designate an active attacker. This type of attacker is able to spoof, alter and intercept message. ↩︎

If the encryption scheme is an authenticated encryption, there is no need for a separate MAC. ↩︎

Using a key derivation function (KDF). For example, TLS v1.3 uses HKDF. ↩︎ ↩︎

In the case where Alice is authenticating using a static DH key pair and Bob is authenticating using a digital signature, Alice is vulnerable to KCI as well: if an attacker manages to get Alice's static DH private key, the attacker can use that key to compute the DH shared secret and hijack the communication. ↩︎

This is the extended version of protocol 1 in

*Modular Security Proofs for Key Agreemen Protocols*, discussed at the end of section 5. ↩︎“What about a double Diffie-Hellman key agreement?”, you might wonder.

If you don't include the ephemeral-ephemeral DH key agreeement (only the two ephemeral-static ones), you don't have forward secrecy with respect to the static DH private keys: if someone manages to compromise the static DH private key of

*both*participants, he can then compute both DH shared secrets and decrypt all previous communications between these two parties. This is protocol 1 in*Modular Security Proofs for Key Agreemen Protocols*.Another option would be to combine an ephemeral-ephemeral DH key exchange (for mutual authentication) and a static-static DH key exchange (for forward secrecy). I

*guess*(?) it would work but would provide weaker**participation repudiation**than 3DH: it would only provide participation repudiation (when any of the two parties can forge a transcript between the two parties) instead of the*full*participation repudiation (when “anybody is able to forge a transcript between any two parties”) provided by 3DH. Moreover, this scheme would be vulnerable to KCI because the authentication would be based on a static-static DH key exchange. ↩︎One might argue that a party should try to detect DH key reuse when communicating with peers and reject the key exchange in this case. ↩︎

The PSK is derived from the Wifi password and the SSID using a password-based key derivation function (PBKDF2-HMAC-SHA1):

PSK = PBKDF2-HMAC-SHA1(passphrase, salt=SSID, iterations=4096, 256 bits)

See for example

*Analysis of the 802.11i 4-Way Handshake*or*How does WPA/WPA2 WiFi security work, and how to crack it?*for details. ↩︎See the

`wpa_psk_file`

configuration in hostapd for a solution to have per-station (i.e. per MAC address) Wifi passphrases. ↩︎