Cryptography / Concepts

Key Exchange & Key Derivation (KDF)

Key establishment is the umbrella process by which endpoints obtain shared keying material. In Diffie-Hellman key agreement, both endpoints derive a matching shared secret without transmitting that secret; key transport instead sends a sender-generated session key protected under the recipient's key, while a Key Encapsulation Mechanism (KEM) sends an encapsulation ciphertext from which both sides obtain a shared secret. Key Derivation Functions (KDFs) turn shared or master secrets into context-bound subkeys for encryption, authentication, and IV generation.

Diffie-Hellman Key Exchange (DH & ECDH)

Standardized by Whitfield Diffie and Martin Hellman, Diffie-Hellman leverages the discrete logarithm problem. Endpoint A and Endpoint B agree on shared public domain parameters g and p (typically pre-established or drawn from a standardized group, not generated fresh per session), then each compute and exchange a public value derived from them — A = g^a mod p and B = g^b mod p — combining the received value with their own private exponent to arrive at the exact same shared secret S:

S = g^(ab) mod p

Diffie-Hellman public key exchange diagram between Alice and Bob deriving a shared secret S.

Diffie-Hellman public exchange: private keys (a, b) remain secret while shared secret S is derived

Intuitive Layman Model: The Paint Mixing Analogy

To understand how two computers arrive at the exact same secret key without ever sending the key over the wire, consider the Paint Mixing Analogy:

Public Base Color: Client and Server agree in the open on a starting color (Yellow). Eavesdroppers see Yellow too.
Private Secret Colors: Client secretly picks Red (keeps in Client RAM). Server secretly picks Blue (keeps in Server RAM).
Public Mixture Exchange:
- Client mixes Red + Yellow → Orange and sends Orange across the wire.
- Server mixes Blue + Yellow → Green and sends Green across the wire.
- Eavesdroppers see Orange and Green crossing the wire, but because un-mixing paint is computationally infeasible in practice (the analogy stands in for the discrete-log problem, which is not proven mathematically impossible to solve — just believed intractable with known algorithms and realistic hardware), they cannot deduce Red or Blue.
Independent Final Mix:
- Client mixes received Green (Yellow + Blue) + secret Red → Brown.
- Server mixes received Orange (Yellow + Red) + secret Blue → Brown.
Identical Secret Key Result: Both endpoints arrive at the exact same secret color (Brown). The secret key (Brown) was never transmitted over the network.

Software Execution Flow

How Software Diffie-Hellman Handshakes Execute Without Transmitting the Shared Secret

A common point of confusion is asking "how does the secret key get passed to the client?"

In this DH/ECDH flow, the shared secret is never transmitted across the network. Neither endpoint sends that secret. Instead, both software engines exchange public values (key shares) derived from agreed domain parameters and compute the same shared secret independently in CPU RAM. This statement does not describe key transport, which sends an encrypted session key, or KEM encapsulation, which sends an encapsulation ciphertext:

Client Exchange (`ClientHello`): Client's crypto engine generates an ephemeral private key a in RAM and sends public key A = a × G over the wire.
Server Exchange (`ServerHello`): Server's crypto engine generates an ephemeral private key b in RAM and sends public key B = b × G over the wire.
Independent Local Calculation:
- Browser calculates: S = a × B = a × (b × G) = a × b × G
- Server calculates: S = b × A = b × (a × G) = a × b × G
Identical Shared Secret & Secret Lifecycle: Both sides arrive at the exact same shared secret S. Neither side uses S directly as a key — a protocol passes it through a KDF such as HKDF to derive context-specific traffic keys and IVs. Security-conscious native implementations should erase superseded ephemeral secrets where their language, runtime, and platform permit it, but the protocol does not guarantee erasure and the exact behavior must be verified. Swap, hibernation, crash dumps, managed runtimes, and implementation defects can preserve secret material after its intended lifetime.

Elliptic Curve Diffie-Hellman (ECDH / X25519)

Modern protocols replace finite-field Diffie-Hellman with Elliptic Curve Diffie-Hellman (ECDH) over Curve25519 (X25519 / RFC 7748) or NIST P-256:

Smaller Public Keys: 32-byte (256-bit) public keys provide 128-bit security, compared to 3072-bit modular prime groups in finite-field DH.
Fast Execution: Meaningfully faster scalar multiplication than equivalent-security finite-field DH — the precise speedup depends on implementation and hardware, so benchmark your target platform rather than treating any fixed multiplier as universal. Curve25519 (X25519) was specifically designed so that constant-time, complete-formula arithmetic is straightforward to implement correctly; NIST P-256 can also be implemented in constant time, but its formulas historically made that easier to get wrong, and constant-time-ness is ultimately a property of a given implementation, not a guarantee either curve provides automatically.

Key Establishment Taxonomy: Agreement vs. Transport vs. KEM Encapsulation

“How do two parties end up with a shared key?” covers three distinct mechanisms that this page (and the Asymmetric Cryptography and PQC pages) otherwise use somewhat interchangeably. They differ in who generates the secret and what a private-key compromise exposes:

Mechanism	Who Generates the Secret	Private-Key Compromise Exposes	Examples
Key Agreement	Neither party alone — both sides’ independent contributions combine into a secret neither could compute without the other’s input	Nothing retroactively, if the contributions were ephemeral (freshly generated per session, then discarded) — this is what makes forward secrecy possible	Diffie-Hellman, ECDH/X25519 (as described above)
Key Transport	The sender — it generates the session key itself and encrypts (transports) it directly under the recipient’s long-term public key	Every session key ever transported under that public key, including past ones — a leaked long-term private key retroactively decrypts recorded traffic (this is exactly the “Static Key Exchange” row in the PFS table below)	Static RSA key transport (e.g., classic TLS RSA cipher suites, now prohibited in TLS 1.3)
KEM Encapsulation	The encapsulating party — it uses the recipient’s public key to produce both a ciphertext and a shared secret in one step; the recipient recovers the same secret via decapsulation	Depends entirely on whether the KEM keypair itself was ephemeral or long-term — a KEM used with a freshly generated keypair per session behaves like agreement for forward-secrecy purposes; one used with a static keypair behaves like transport	ML-KEM (FIPS 203), the hybrid X25519MLKEM768 group’s ML-KEM component (see the Post-Quantum Cryptography page)

The recurring confusion across this section is treating all three as interchangeable “key exchange.” They aren’t: agreement and (ephemeral) KEM encapsulation both support forward secrecy; transport and (static) KEM encapsulation don’t. Whether a given key-establishment step provides forward secrecy is a property of how the keys involved are generated and reused, not of which mathematical primitive (DH, RSA, lattice-based KEM) is doing the underlying work.

Authenticated Key Exchange & MITM Prevention

Unauthenticated Diffie-Hellman (Anonymous DH/ECDH) provides confidentiality against passive eavesdroppers, but is fundamentally vulnerable to active Man-in-the-Middle (MITM) attacks. An active adversary intercepting the network connection can negotiate independent shared secrets with both parties, decrypting and re-encrypting all traffic transparently.

When peer identity and active-MITM resistance are security objectives — as they are for essentially all internet-facing key exchange — the exchange must be authenticated to prevent MITM key substitution. (Anonymous or opportunistic DH, which deliberately forgoes this, has narrower legitimate uses, like defending only against passive eavesdroppers where authentication infrastructure isn’t available.) The common authentication mechanisms:

Digital Signatures (TLS 1.3): TLS 1.3 does not simply sign the ephemeral ECDH key share in isolation; CertificateVerify signs the complete handshake transcript, which includes and therefore cryptographically binds the exchanged key shares per RFC 9846 bound to a verified X.509 certificate (RSA-PSS, ECDSA, or Ed25519, per the negotiated signature_algorithms).
Pre-Shared Keys (PSK): Both parties share a pre-configured high-entropy secret used to authenticate the key exchange.
Mutual TLS (mTLS): Both client and server present X.509 certificates and verify digital signatures over the handshake transcript.

Furthermore, raw Diffie–Hellman produces a shared-secret value, not a ready-to-use key. Applications should pass that value through a protocol-defined Key Derivation Function (HKDF / RFC 5869) to derive independent, context-bound traffic keys rather than using it directly as an AEAD key.

Password-Authenticated Key Exchange (PAKE)

The PSK row above assumes a high-entropy pre-shared secret — one an offline brute-force search can’t feasibly enumerate. A low-entropy human password doesn’t meet that bar, and using one as an ordinary PSK is dangerous: anyone who observes the exchange (or compromises a party that verifies it insecurely) can run an offline dictionary attack against the password itself. PAKE (Password-Authenticated Key Exchange) protocols exist specifically to let two parties establish an authenticated shared key from a low-entropy password without exposing it to that kind of offline attack — an eavesdropper who records the entire exchange still can’t do better than the online guessing rate the server itself can rate-limit.

Symmetric vs. augmented PAKE: In a symmetric (balanced) PAKE, both sides hold the same password-derived secret directly — appropriate when both endpoints are equally trusted with the password (e.g., two peers establishing a shared session from a common passphrase). In an augmented (asymmetric) PAKE, the client holds the password but the server holds only a derived registration record — never the password itself, and not something from which the password can be directly recovered — so a server-side data breach doesn’t hand the attacker a password-equivalent secret usable to impersonate the client elsewhere.
Resistance to offline guessing: A PAKE’s core security property is that the protocol transcript an eavesdropper observes gives no information usable for offline password guessing — every guess an attacker makes has to be checked interactively against the live server (which can rate-limit or lock out repeated failures), not verified silently against captured data. This is a guarantee about a specific attacker state — a passive network observer of the live exchange — and it’s worth not conflating with a different attacker state: “password sent over TLS” already protects the password from that same passive network observer during transmission, but that’s a transport-layer property, separate from what happens to the password after it reaches the server. Once stored, an ordinary salted-hash verifier is directly offline-guessable if the credential store is later breached (see the Password Storage page) — a stored-credential compromise, not a network-observation one. A PAKE’s passive-transcript protection doesn’t by itself say anything about that separate, later risk; whether the stored server-side data also resists offline guessing after a breach depends on the specific PAKE variant (see the augmented-PAKE registration-record discussion below, including its own limits under full server compromise).
Server registration records: For an augmented PAKE, the server-side record is deliberately not the password and not a simple salted hash of it. Unlike a conventional salted password hash — which by itself is enough to mount an offline guessing attack — the OPAQUE registration record alone is insufficient for that; the relevant server-side OPRF secrets are also required (see the Password Storage page for how salted-hash storage compares). But that’s narrower protection than it sounds, for two reasons. First, RFC 9807 itself is explicit that offline dictionary attacks are not eliminated by OPAQUE, only made harder: a server compromise that yields both the stored registration record and any server-side secrets needed to use it still lets an attacker run an offline guessing attack against the password. Second, if that offline attack succeeds, the attacker recovers the actual password — a credential that is directly reusable anywhere the user reused it, so the registration record’s non-reusability doesn’t survive a successful password recovery. A key-stretching function (KSF, e.g. Argon2id) raises the cost per guess, the same role it plays in ordinary password storage, but it doesn’t make a low-entropy password’s recovery infeasible; PAKE’s offline-guessing resistance is specifically about the live network protocol exchange, not a guarantee that survives full server compromise.
Transcript binding and key confirmation: Like the authenticated-DH mechanisms above, a well-designed PAKE binds the derived session key to the specific protocol transcript and includes explicit key-confirmation messages (MAC-authenticated protocol messages) so each side proves it derived the same key before either trusts the channel — the same principle as the key-confirmation discussion on the Asymmetric Cryptography page, applied to a password-derived exchange instead of a certificate-authenticated one.
OPAQUE: RFC 9807 specifies OPAQUE, a current augmented PAKE built from an Oblivious Pseudorandom Function (OPRF) plus an authenticated key exchange phase. The client’s password never leaves the client in a form the server can use to reconstruct it; the server-side registration record includes an encrypted “envelope” that only a correct password can unlock, and the AKE phase performs explicit key confirmation over the full transcript. Its real advantages over a plain password-over-TLS design aren’t about what a server breach exposes: a leaked password hash directly enables offline guessing on its own, while OPAQUE’s registration record alone doesn’t — offline guessing there requires the fuller single-server compromise described in the server-registration-record entry above, exposing both the record and the server-side OPRF secrets needed to use it. The advantages instead are that the password itself is never transmitted to or seen in the clear by the server at all (password hiding), that a passive eavesdropper on the network exchange gains nothing usable toward offline guessing, and that the OPRF step specifically blocks precomputation attacks against the credential. RFC 9807 §1 also describes OPAQUE as PKI-free, but with a specific carve-out: PKI (or some other authenticated channel) is still needed during initial client registration, so “PKI-free” describes ongoing authentication, not the full protocol lifecycle.

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (PFS) ensures that, provided the per-session ephemeral key material was not itself separately compromised, an adversary who later obtains a long-term server private key cannot use it to decrypt previously recorded session traffic.

Protocol Property	Static Key Exchange (Deprecated)	Ephemeral Key Exchange (PFS Standard)
Impact of Private Key Leak	In deployments that use the leaked long-term key to transport or derive session keying material — static RSA key transport or static, non-ephemeral Diffie-Hellman — the adversary can decrypt recorded historical traffic protected under that key when the required transcript or ciphertext was captured.	An adversary cannot derive past session keys from the leaked long-term authentication key alone; recorded sessions remain protected unless the ephemeral key-establishment secrets or another required input were independently compromised.
Key-Establishment Mechanics	RSA key transport or static Diffie-Hellman	Fresh finite-field DH, ECDHE/X25519, or an ephemeral hybrid group such as X25519MLKEM768
Modern Protocol Boundary	Static RSA key transport and static DH are absent from TLS 1.3 (RFC 9846, which obsoletes the original RFC 8446).	Certificate-authenticated TLS 1.3 full handshakes use ephemeral key establishment; standardized groups include finite-field DH, ECDHE, and hybrid ECDHE+ML-KEM. TLS 1.3 also permits PSK-only operation without `psk_dhe_ke`, which forgoes forward secrecy for that connection. SSHv2 similarly favors ephemeral ECDH/DH methods, but RFC 9142 defines per-algorithm implementation tiers rather than one universal ephemeral-only rule.

Architectural Roles

Server Authentication Key vs. Ephemeral Key-Establishment Secrets

Understanding key roles resolves common misconceptions between identity authentication and data encryption:

Server Certificate Key (Typically on Disk, an HSM, or a KMS): In a certificate-authenticated TLS 1.3 handshake, this key provides identity authentication by signing the handshake transcript. It is not the bulk-data encryption key; record-layer traffic keys are derived separately from the key-agreement result. This describes the key's TLS role rather than every use another certificate profile might permit.
Ephemeral Key-Establishment Secrets (Intended to Stay in Memory Only): A certificate-authenticated TLS 1.3 full handshake uses fresh finite-field DH, ECDHE/X25519, or a hybrid ECDHE+ML-KEM group to establish shared secret material. Those values are key-establishment inputs, not traffic-encryption keys themselves. The TLS HKDF key schedule derives the negotiated AEAD traffic keys and IVs. Superseded secrets are intended to be discarded, but erasure is an implementation goal rather than a protocol guarantee; swap, hibernation, managed runtimes, or crash dumps can preserve them.
Client Certificates: In ordinary web browsing, clients normally do not present certificates. The browser still contributes ephemeral key-establishment material and derives traffic secrets through the TLS key schedule; server authentication and client authentication are separate from that confidentiality mechanism.

Perfect Forward Secrecy Simulation Playground

Interactive Browser Playground

Perfect Forward Secrecy (PFS) Simulator

Simulate key transport and key agreement protocols directly in your browser. Establish connections, simulate a server key compromise, and check whether historical session data can be decrypted. Simplified for illustration: the "Ephemeral ECDH" mode signs only the server's ephemeral key share against a freshly generated key, not the full handshake transcript against a CA-trusted certificate the way real TLS 1.3 does.

Step 1: Session 1 (Past Connection)

Establish a secure connection and transmit data.

Step 2: Session 2 (Recent Connection)

Establish a second connection and transmit data. Eavesdroppers record all traffic.

Step 3: Server Key Compromise

Steal the long-term identity private key from the server storage.

Step 4: Attempt Decryption of Historical Traffic

Attacker attempts to decrypt past connection ciphertexts using the stolen server key.

Key Derivation Functions: HKDF (RFC 5869) & HPKE

A raw Diffie-Hellman shared secret S often contains non-uniform entropy and cannot be used directly as an AES key. A Key Derivation Function (KDF) transforms raw input key material (IKM) into pseudo-random key material (PRK) and expands it into multiple target keys.

Standardized in RFC 5869, HKDF follows a two-stage Extract-then-Expand pipeline:

HKDF Extract-then-Expand pipeline: HMAC-based entropy extraction and key expansion

1. Extract Phase

Extracts uniform pseudorandom key PRK from input key material IKM and an optional salt:

PRK = HMAC-Hash(Salt, IKM)

2. Expand Phase

Internally, HKDF-Expand builds its output keying material (OKM) block by block, and each block feeds into the next — the formula from RFC 5869 §2.3 is:

T(i) = HMAC(PRK, T(i−1) || info || i), with T(0) defined as the empty string

Expands PRK into sub-keys of any length up to HKDF-Expand’s own bound — RFC 5869 §2.3 caps output at 255 × HashLen bytes, not an arbitrary length — using application-specific info context strings. Generic RFC 5869 applications call HKDF-Expand with a plain info byte string directly, e.g.:

Traffic_Key = HKDF-Expand(PRK, info, length)

TLS 1.3 itself does not call raw HKDF-Expand with a bare label string like "tls13 client write" — RFC 9846 §7.1 defines a wrapper, HKDF-Expand-Label, that builds a structured info field (encoding the output length, a "tls13 "-prefixed label, and an optional context) before calling HKDF-Expand:

HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length)

where HkdfLabel is the serialized structure { Length, "tls13 " + Label, Context }. Traffic keys are then derived via the further wrapper Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length).

Hybrid Public Key Encryption (HPKE / RFC 9180) & Post-Quantum KEMs

Specified in RFC 9180, HPKE standardizes a Key Encapsulation Mechanism (KEM), a KDF (HKDF), and an AEAD cipher into a single modular primitive.

Post-Quantum KEM Transition (FIPS 203 ML-KEM)

Classical ECDH key agreement (X25519) is vulnerable to quantum computers. Protocols are transitioning to post-quantum-secure key exchange, though adoption varies and is not yet universal. TLS 1.3 is a concrete, already-standardized example: RFC 10024 defines the hybrid X25519MLKEM768 group, combining classical X25519 ECDH with NIST FIPS 203 ML-KEM-768 (Kyber), to establish post-quantum-resistant shared secrets.

What I need to remember

Diffie-Hellman lets both sides derive the same shared secret in RAM without ever transmitting it; ephemeral keys (ECDHE/X25519) provide forward secrecy so a later leak of a long-term key can't decrypt past sessions. HKDF then extracts and expands that raw shared secret into independent traffic sub-keys.

Primary references

RFC 7748: Elliptic Curves for Security (X25519) — RFC 7748 (IRTF/CFRG Informational)
RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) — IETF RFC 5869
RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 — IETF RFC 9846
RFC 9807: The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE) Protocol — RFC 9807 (IRTF/CFRG Informational)