Computer NetworksAsymmetric Encryption

Asymmetric Encryption

LevelIntermediate

Duration75 mins

TopicAsymmetric Encryption

4 / 5

Key Exchange

The Problem That Started It All

In 1976, Whitfield Diffie and Martin Hellman proposed something that seemed impossible: two parties could agree on a secret key while communicating only over a public channel. An eavesdropper, listening to every single bit of their exchange, would be unable to determine the shared secret.

This revolutionary idea—the Diffie-Hellman key exchange—didn't just solve the key distribution problem; it fundamentally changed our understanding of what cryptography could achieve. Before DH, shared secrets required physical exchange or trusted couriers. After DH, two strangers could establish a secure channel from opposite sides of the planet.

Key exchange protocols are the foundation of modern internet security. Every TLS handshake that secures your banking session, every SSH connection to a server, every VPN tunnel protecting your traffic—all begin with some form of key exchange. Understanding these protocols is essential for understanding how secure communication actually works.

What You Will Learn

By the end of this page, you will understand how key exchange protocols enable two parties to establish a shared secret over a public channel, the mathematics behind Diffie-Hellman and its elliptic curve variant (ECDH), why ephemeral keys provide forward secrecy, and how these protocols are authenticated in practice.

The Key Exchange Problem

Before diving into solutions, let's clearly define the problem:

Scenario:

Alice wants to communicate securely with Bob
They have never communicated before (no pre-shared secrets)
All communication channels are assumed to be monitored by Eve
They want to establish a shared symmetric key for encrypting their conversation

Constraints:

Any message Alice sends to Bob, Eve also receives
Any message Bob sends to Alice, Eve also receives
Eve has unlimited storage and computational resources (within polynomial time)
There is no trusted third party to mediate

The Seemingly Impossible Goal:

After the exchange, Alice and Bob share a key K that:

Is unknown to Eve (despite Eve seeing all transmitted messages)
Is identical for both Alice and Bob
Can be used for symmetric encryption

Converting Mermaid diagram...

Why Naive Approaches Fail:

Approach	Why It Fails
Alice sends key to Bob	Eve intercepts and copies it
Alice encrypts key with Bob's public key	Works! But requires Bob to already have a key pair
Use a trusted third party	Single point of failure; doesn't scale
Physical exchange	Impractical for internet communication

The second approach (public-key encryption of a symmetric key) does work and is used in practice. But Diffie-Hellman offers something different: a way to jointly compute a shared secret without either party choosing it unilaterally. This has important security properties, especially when combined with ephemeral keys.

Public Key Encryption vs Key Exchange

While both solve key distribution, they're conceptually different. In encryption, one party chooses the secret and sends it (encrypted). In key exchange, both parties contribute randomness, and neither can control the final secret. This distinction matters for security properties like contributory key generation.

Diffie-Hellman Key Exchange

The Diffie-Hellman (DH) key exchange is one of the most elegant algorithms in cryptography. It relies on the difficulty of the discrete logarithm problem: given g, p, and g^x mod p, finding x is computationally infeasible.

The Protocol:

Public Parameters (known to everyone, including Eve):

p: A large prime number (2048+ bits)
g: A generator of the multiplicative group modulo p

Alice's Actions:

Generate random secret integer a (1 < a < p-1)
Compute A = g^a mod p
Send A to Bob

Bob's Actions:

Generate random secret integer b (1 < b < p-1)
Compute B = g^b mod p
Send B to Alice

Computing the Shared Secret:

Alice computes: K = B^a mod p = (g^b)^a mod p = g^(ab) mod p
Bob computes: K = A^b mod p = (g^a)^b mod p = g^(ab) mod p

Both compute the same value K = g^(ab) mod p!

diffie_hellman.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Diffie-Hellman Key Exchange
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
PUBLIC PARAMETERS:
p = large prime (e.g., 2048 bits)
g = generator of Z*p (typically 2 or 5)
 
ALICE                                    BOB
─────                                    ───
Generate random a                        Generate random b
(1 < a < p-1)                           (1 < b < p-1)
 
Compute A = g^a mod p                    Compute B = g^b mod p
 
        ─────▶ Send A ─────▶
        ◀───── Send B ◀─────
 
Compute K = B^a mod p                    Compute K = A^b mod p
         = g^(ab) mod p                           = g^(ab) mod p
 
★ SHARED SECRET: K = g^(ab) mod p ★
 
EVE SEES: p, g, A = g^a mod p, B = g^b mod p
EVE CANNOT COMPUTE: g^(ab) mod p (Computational Diffie-Hellman problem)

Converting Mermaid diagram...

Why Eve Cannot Compute K:

Eve sees: p, g, A = g^a mod p, B = g^b mod p

To compute K = g^(ab) mod p, Eve would need to:

Compute a from A (discrete log problem: find a such that g^a ≡ A mod p)
Or compute b from B (same problem)
Or directly compute g^(ab) from g^a and g^b (Computational Diffie-Hellman problem)

All of these are believed to be computationally infeasible for properly chosen parameters. The best known algorithms for discrete log have sub-exponential complexity (number field sieve), requiring astronomical resources for 2048+ bit primes.

Security Note: The raw shared secret K should never be used directly as an encryption key. Instead, it's passed through a Key Derivation Function (KDF) to produce properly-formatted key material.

The Paint-Mixing Analogy Revisited

Think of g as a public base color, a and b as secret colors only Alice and Bob know, and modular exponentiation as mixing. Alice mixes g with a to get A, Bob mixes g with b to get B. When Alice mixes B with a, and Bob mixes A with b, they get the same final color—but separating mixed paint to find the secret colors is nearly impossible.

Elliptic Curve Diffie-Hellman (ECDH)

Elliptic Curve Diffie-Hellman (ECDH) is the modern variant of DH, offering equivalent security with much smaller key sizes and faster operations.

The Key Insight:

Instead of working in the multiplicative group of integers modulo p, ECDH works in the group of points on an elliptic curve. The discrete logarithm problem on properly chosen elliptic curves is harder than in finite fields, allowing smaller keys.

ECDH Protocol:

Public Parameters:

Curve parameters: a, b, p defining y² = x³ + ax + b mod p
Generator point G on the curve
Order n (number of points in the group)

Alice's Actions:

Generate random secret integer a (1 ≤ a < n)
Compute point A = a × G (scalar multiplication)
Send A to Bob

Bob's Actions:

Generate random secret integer b (1 ≤ b < n)
Compute point B = b × G
Send B to Alice

Shared Secret:

Alice computes: K = a × B = a × (b × G) = (ab) × G
Bob computes: K = b × A = b × (a × G) = (ab) × G

Both arrive at the same point K on the curve!

DH vs ECDH: Key Size and Security Comparison
Security Level	DH/RSA Key Size	ECDH Key Size	Size Reduction
80-bit (deprecated)	1024 bits	160 bits	6.4x
112-bit (minimum)	2048 bits	224 bits	9.1x
128-bit (recommended)	3072 bits	256 bits	12x
192-bit (high security)	7680 bits	384 bits	20x
256-bit (ultra security)	15360 bits	512 bits	30x

ecdh.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Elliptic Curve Diffie-Hellman (using P-256)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
CURVE PARAMETERS (NIST P-256):
p = 2^256 - 2^224 + 2^192 + 2^96 - 1
a = -3
b = 0x5ac635d8aa3a93e7b3ebbd55769886bc...
G = (Gx, Gy) base point on curve
n = order of G ≈ 2^256
 
ALICE                                    BOB
─────                                    ───
Generate random a ∈ [1, n-1]            Generate random b ∈ [1, n-1]
 
Compute A = a × G                        Compute B = b × G
(point multiplication)                   (point multiplication)
 
        ─────▶ Send A (point) ─────▶
        ◀───── Send B (point) ◀─────
 
Compute K = a × B                        Compute K = b × A
         = a × (b × G)                            = b × (a × G)
         = (ab) × G                               = (ab) × G
 
★ SHARED SECRET: K = (ab) × G ★
 
Typically: shared_key = KDF(K.x)  // Use x-coordinate with KDF

ECDH Advantages

•256-bit key = 3072-bit DH security
•5-10x faster than equivalent DH
•Smaller messages (efficient for IoT)
•Less memory and bandwidth
•Well-suited for constrained devices

Popular ECDH Curves

•P-256 (secp256r1): NIST, most common
•P-384 (secp384r1): Higher security
•X25519 (Curve25519): Modern, fast
•X448: Even higher security
•secp256k1: Bitcoin/Ethereum

X25519: The Modern Standard

X25519 (Curve25519 for key exchange) is increasingly preferred over NIST curves. Designed by Daniel Bernstein, it's faster, has cleaner implementation properties, and lacks the 'nothing up my sleeve' concerns of NIST curve constants. TLS 1.3, Signal, WireGuard, and modern SSH all use X25519 by default.

Forward Secrecy with Ephemeral Keys

Forward secrecy (also called perfect forward secrecy or PFS) is a critical security property that protects past communications even if long-term keys are later compromised.

The Problem with Static Keys:

Consider a naive key exchange where Alice always uses the same private key a:

Eve records all encrypted traffic and DH exchanges
Years later, Alice's private key a is compromised (theft, court order, cryptographic breakthrough)
Eve can now compute all past shared secrets: K = B^a for every recorded B
All historical communications are decrypted

The Solution: Ephemeral Keys

With ephemeral (temporary) keys, each session uses a freshly generated key pair:

Alice generates a new random a for this session only
Alice computes A = g^a, performs key exchange
After the session, Alice securely deletes a
Even if Alice's long-term identity key is compromised, the session key cannot be recovered—a no longer exists

Converting Mermaid diagram...

Key Exchange Modes and Forward Secrecy
Mode	Notation	Forward Secrecy	Description
Static-Static	DH	No	Both parties use long-term keys
Static-Ephemeral	DHE (server ephemeral)	Partial	One party uses ephemeral key
Ephemeral-Ephemeral	DHE (full)	Yes	Both parties use ephemeral keys
ECDH Static	ECDH	No	ECC with static keys
ECDH Ephemeral	ECDHE	Yes	ECC with ephemeral keys (modern TLS)

TLS and Forward Secrecy:

TLS 1.3 mandates ephemeral key exchange (ECDHE or DHE). Older cipher suites like RSA key exchange (where the client encrypts a random value with the server's RSA public key) do not provide forward secrecy and are deprecated.

TLS 1.2 (forward secrecy depends on cipher suite):

TLS_RSA_WITH_AES_256_GCM_SHA384: NO forward secrecy
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: YES forward secrecy

TLS 1.3 (all cipher suites have forward secrecy):

TLS_AES_256_GCM_SHA384: Requires ECDHE or DHE
No RSA key exchange allowed

Why Forward Secrecy Matters

Intelligence agencies and criminals routinely record encrypted traffic speculating that keys might be compromised in the future. Without forward secrecy, a future key compromise exposes years of historical data. With forward secrecy, each session is protected independently—compromising one session reveals nothing about others.

Authenticated Key Exchange

Raw Diffie-Hellman is vulnerable to man-in-the-middle (MITM) attacks. It establishes a shared secret, but provides no assurance of who you're sharing it with.

The MITM Attack on Unauthenticated DH:

Converting Mermaid diagram...

Solutions: Authenticated Key Exchange

Several mechanisms authenticate DH exchanges:

1. Station-to-Station (STS) Protocol:

After DH exchange, both parties sign the transcript
Signatures prove identity and prevent MITM
Used in IKE (IPsec key exchange)

2. SIGn-and-MAc (SIGMA) Protocol:

Signs identity and DH values
MACs the messages with derived key
Basis for IKEv2

3. TLS Handshake:

Server signs its DH value with certificate private key
Client verifies signature using server's certificate
Optional client authentication via client certificates

4. PAKE (Password-Authenticated Key Exchange):

Uses a shared password to authenticate
Resistant to offline dictionary attacks
Examples: SRP, SPAKE2, OPAQUE

authenticated_dh.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Authenticated DH (TLS 1.3 style, simplified)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
CLIENT                                   SERVER
──────                                   ──────
Generate ephemeral a                     Has certificate with signing key
 
Compute A = g^a                          Generate ephemeral b
                                         Compute B = g^b
        ─────▶ ClientHello + A ─────▶
 
                                         signature = Sign(server_key, 
                                                         transcript || B)
 
        ◀─── ServerHello + B + Cert + signature ◀───
 
Verify certificate chain
Verify signature over B using Cert
 
      K = B^a = g^(ab)                   K = A^b = g^(ab)
 
★ AUTHENTICATED shared secret established! ★
 
Now:
- Client knows server is authentic (signature verified)
- Even MITM cannot forge signature without server's private key

Mutual Authentication

TLS typically authenticates only the server. For mutual authentication (where the server also verifies the client), the client presents its own certificate and signs the handshake transcript. This is used in enterprise environments and mTLS-based service meshes.

Key Exchange in TLS 1.3

TLS 1.3 represents the state of the art in authenticated key exchange for the web. Let's trace through its key exchange process.

TLS 1.3 Key Exchange Overview:

TLS 1.3 uses a simplified handshake that's both faster and more secure than TLS 1.2. Key exchange happens immediately, with encryption beginning after just one round trip.

Converting Mermaid diagram...

Key Schedule and Key Derivation:

TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) to derive multiple keys from the shared secret:

                    0
                    |
                    v
              [Early Secret]
                    |
          +--------+--------+
          |                 |
    [binder_key]      [client_early_traffic_secret]
                            |
                            v
                    (ECDH Secret)
                            |
                            v
              [Handshake Secret]
                    |
          +--------+--------+
          |                 |
[c_hs_traffic_secret] [s_hs_traffic_secret]
                            |
                            v
                     [Master Secret]
                            |
          +--------+--------+--------+
          |                 |        |
[c_ap_traffic_secret] [s_ap_traffic_secret] [resumption_secret]

Derived Keys:

Handshake secrets: Encrypt handshake messages after ServerHello
Application secrets: Encrypt application data
Resumption secret: Enables session resumption without full handshake

TLS 1.3 Supported Key Exchange Groups
Group	Security Level	Performance	Notes
x25519	~128 bits	Fastest	Preferred for most uses
secp256r1 (P-256)	~128 bits	Fast	NIST curve, widely supported
x448	~224 bits	Medium	Higher security than x25519
secp384r1 (P-384)	~192 bits	Medium	Government/enterprise
secp521r1 (P-521)	~256 bits	Slower	Highest ECC security
ffdhe2048	~112 bits	Slow	Finite field DH, legacy
ffdhe3072	~128 bits	Slow	Finite field DH, more secure

0-RTT: Speed with Tradeoffs

TLS 1.3 supports 0-RTT (zero round-trip time) resumption, where returning clients can send encrypted data immediately. However, 0-RTT data can be replayed by an attacker, so it's only suitable for idempotent requests. Use with caution.

Practical Key Exchange

Let's see how key exchange is implemented in practice with code examples.

ECDH Key Exchange Examples:

ecdh_key_exchange.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
const crypto = require('crypto');
 
// Simulate Alice and Bob performing ECDH key exchange
 
// Alice generates her key pair
const alice = crypto.createECDH('prime256v1');  // P-256 curve
alice.generateKeys();
const alicePublicKey = alice.getPublicKey();
 
// Bob generates his key pair
const bob = crypto.createECDH('prime256v1');
bob.generateKeys();
const bobPublicKey = bob.getPublicKey();
 
// Exchange public keys (over network)
// Alice computes shared secret using Bob's public key
const aliceSharedSecret = alice.computeSecret(bobPublicKey);
 
// Bob computes shared secret using Alice's public key
const bobSharedSecret = bob.computeSecret(alicePublicKey);
 
// Verify they got the same shared secret
console.log('Alice shared secret:', aliceSharedSecret.toString('hex'));
console.log('Bob shared secret:  ', bobSharedSecret.toString('hex'));
console.log('Secrets match:', 
    aliceSharedSecret.equals(bobSharedSecret));
 
// Derive encryption key using HKDF
const derivedKey = crypto.hkdfSync(
    'sha256',
    aliceSharedSecret,
    Buffer.alloc(0),  // No salt for simplicity
    Buffer.from('encryption key'),
    32  // 256-bit key
);
console.log('Derived AES key:', derivedKey.toString('hex'));

Important Implementation Considerations:

Consideration	Best Practice
Curve selection	Use X25519 or P-256; avoid weak curves
Private key handling	Generate fresh for each session, securely delete after
Key derivation	Always use HKDF or similar KDF, never raw shared secret
Public key validation	Verify received point is on the curve
Side channels	Use constant-time implementations
Error handling	Don't leak information through error messages

Never Skip Key Derivation

The raw ECDH shared secret should never be used directly as an encryption key. It's biased (not uniformly random) and may have structure an attacker could exploit. Always pass it through a KDF (HKDF, SHA-256, etc.) to produce proper key material.

Summary: Key Exchange Mastery

We've explored the fascinating world of key exchange protocols. Let's consolidate the key takeaways:

Key Takeaways

•Diffie-Hellman enables shared secrets over public channels — Using the discrete logarithm problem, two parties compute a shared secret that eavesdroppers cannot determine.
•ECDH is the modern standard — Elliptic curve DH provides equivalent security with smaller keys and faster operations.
•Ephemeral keys enable forward secrecy — By using fresh keys for each session and deleting them afterward, past sessions remain secure even if long-term keys are compromised.
•Authentication is essential — Raw DH is vulnerable to MITM attacks; signatures or certificates must authenticate the exchange.
•TLS 1.3 exemplifies best practices — Mandatory forward secrecy, authenticated key exchange, and modern cipher suites.
•Key derivation is mandatory — Raw shared secrets must be processed through KDFs before use as encryption keys.

What's Next:

The final page in this module compares asymmetric encryption with symmetric encryption—understanding when to use each, their complementary roles in hybrid systems, and the performance and security tradeoffs that guide real-world cryptographic design decisions.

Page Complete

You now understand key exchange protocols—from the revolutionary Diffie-Hellman algorithm to modern ECDHE in TLS 1.3. This knowledge explains how secure channels are established on the internet and why forward secrecy is critical for protecting communications against future compromise.

4 / 5

Loading learning content...

Computer NetworksAsymmetric Encryption

Asymmetric Encryption

LevelIntermediate

Duration75 mins

TopicAsymmetric Encryption

4 / 5

Key Exchange

The Problem That Started It All

What You Will Learn

The Key Exchange Problem

Before diving into solutions, let's clearly define the problem:

Scenario:

Alice wants to communicate securely with Bob
They have never communicated before (no pre-shared secrets)
All communication channels are assumed to be monitored by Eve
They want to establish a shared symmetric key for encrypting their conversation

Constraints:

Any message Alice sends to Bob, Eve also receives
Any message Bob sends to Alice, Eve also receives
Eve has unlimited storage and computational resources (within polynomial time)
There is no trusted third party to mediate

The Seemingly Impossible Goal:

After the exchange, Alice and Bob share a key K that:

Is unknown to Eve (despite Eve seeing all transmitted messages)
Is identical for both Alice and Bob
Can be used for symmetric encryption

Converting Mermaid diagram...

Why Naive Approaches Fail:

Approach	Why It Fails
Alice sends key to Bob	Eve intercepts and copies it
Alice encrypts key with Bob's public key	Works! But requires Bob to already have a key pair
Use a trusted third party	Single point of failure; doesn't scale
Physical exchange	Impractical for internet communication

Public Key Encryption vs Key Exchange

Diffie-Hellman Key Exchange

The Protocol:

Public Parameters (known to everyone, including Eve):

p: A large prime number (2048+ bits)
g: A generator of the multiplicative group modulo p

Alice's Actions:

Generate random secret integer a (1 < a < p-1)
Compute A = g^a mod p
Send A to Bob

Bob's Actions:

Generate random secret integer b (1 < b < p-1)
Compute B = g^b mod p
Send B to Alice

Computing the Shared Secret:

Alice computes: K = B^a mod p = (g^b)^a mod p = g^(ab) mod p
Bob computes: K = A^b mod p = (g^a)^b mod p = g^(ab) mod p

Both compute the same value K = g^(ab) mod p!

diffie_hellman.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Diffie-Hellman Key Exchange
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
PUBLIC PARAMETERS:
p = large prime (e.g., 2048 bits)
g = generator of Z*p (typically 2 or 5)
 
ALICE                                    BOB
─────                                    ───
Generate random a                        Generate random b
(1 < a < p-1)                           (1 < b < p-1)
 
Compute A = g^a mod p                    Compute B = g^b mod p
 
        ─────▶ Send A ─────▶
        ◀───── Send B ◀─────
 
Compute K = B^a mod p                    Compute K = A^b mod p
         = g^(ab) mod p                           = g^(ab) mod p
 
★ SHARED SECRET: K = g^(ab) mod p ★
 
EVE SEES: p, g, A = g^a mod p, B = g^b mod p
EVE CANNOT COMPUTE: g^(ab) mod p (Computational Diffie-Hellman problem)

Converting Mermaid diagram...

Why Eve Cannot Compute K:

Eve sees: p, g, A = g^a mod p, B = g^b mod p

To compute K = g^(ab) mod p, Eve would need to:

Compute a from A (discrete log problem: find a such that g^a ≡ A mod p)
Or compute b from B (same problem)
Or directly compute g^(ab) from g^a and g^b (Computational Diffie-Hellman problem)

Security Note: The raw shared secret K should never be used directly as an encryption key. Instead, it's passed through a Key Derivation Function (KDF) to produce properly-formatted key material.

The Paint-Mixing Analogy Revisited

Elliptic Curve Diffie-Hellman (ECDH)

Elliptic Curve Diffie-Hellman (ECDH) is the modern variant of DH, offering equivalent security with much smaller key sizes and faster operations.

The Key Insight:

ECDH Protocol:

Public Parameters:

Curve parameters: a, b, p defining y² = x³ + ax + b mod p
Generator point G on the curve
Order n (number of points in the group)

Alice's Actions:

Generate random secret integer a (1 ≤ a < n)
Compute point A = a × G (scalar multiplication)
Send A to Bob

Bob's Actions:

Generate random secret integer b (1 ≤ b < n)
Compute point B = b × G
Send B to Alice

Shared Secret:

Alice computes: K = a × B = a × (b × G) = (ab) × G
Bob computes: K = b × A = b × (a × G) = (ab) × G

Both arrive at the same point K on the curve!

DH vs ECDH: Key Size and Security Comparison
Security Level	DH/RSA Key Size	ECDH Key Size	Size Reduction
80-bit (deprecated)	1024 bits	160 bits	6.4x
112-bit (minimum)	2048 bits	224 bits	9.1x
128-bit (recommended)	3072 bits	256 bits	12x
192-bit (high security)	7680 bits	384 bits	20x
256-bit (ultra security)	15360 bits	512 bits	30x

ecdh.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Elliptic Curve Diffie-Hellman (using P-256)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
CURVE PARAMETERS (NIST P-256):
p = 2^256 - 2^224 + 2^192 + 2^96 - 1
a = -3
b = 0x5ac635d8aa3a93e7b3ebbd55769886bc...
G = (Gx, Gy) base point on curve
n = order of G ≈ 2^256
 
ALICE                                    BOB
─────                                    ───
Generate random a ∈ [1, n-1]            Generate random b ∈ [1, n-1]
 
Compute A = a × G                        Compute B = b × G
(point multiplication)                   (point multiplication)
 
        ─────▶ Send A (point) ─────▶
        ◀───── Send B (point) ◀─────
 
Compute K = a × B                        Compute K = b × A
         = a × (b × G)                            = b × (a × G)
         = (ab) × G                               = (ab) × G
 
★ SHARED SECRET: K = (ab) × G ★
 
Typically: shared_key = KDF(K.x)  // Use x-coordinate with KDF

ECDH Advantages

•256-bit key = 3072-bit DH security
•5-10x faster than equivalent DH
•Smaller messages (efficient for IoT)
•Less memory and bandwidth
•Well-suited for constrained devices

Popular ECDH Curves

•P-256 (secp256r1): NIST, most common
•P-384 (secp384r1): Higher security
•X25519 (Curve25519): Modern, fast
•X448: Even higher security
•secp256k1: Bitcoin/Ethereum

X25519: The Modern Standard

Forward Secrecy with Ephemeral Keys

Forward secrecy (also called perfect forward secrecy or PFS) is a critical security property that protects past communications even if long-term keys are later compromised.

The Problem with Static Keys:

Consider a naive key exchange where Alice always uses the same private key a:

Eve records all encrypted traffic and DH exchanges
Years later, Alice's private key a is compromised (theft, court order, cryptographic breakthrough)
Eve can now compute all past shared secrets: K = B^a for every recorded B
All historical communications are decrypted

The Solution: Ephemeral Keys

With ephemeral (temporary) keys, each session uses a freshly generated key pair:

Alice generates a new random a for this session only
Alice computes A = g^a, performs key exchange
After the session, Alice securely deletes a
Even if Alice's long-term identity key is compromised, the session key cannot be recovered—a no longer exists

Converting Mermaid diagram...

Key Exchange Modes and Forward Secrecy
Mode	Notation	Forward Secrecy	Description
Static-Static	DH	No	Both parties use long-term keys
Static-Ephemeral	DHE (server ephemeral)	Partial	One party uses ephemeral key
Ephemeral-Ephemeral	DHE (full)	Yes	Both parties use ephemeral keys
ECDH Static	ECDH	No	ECC with static keys
ECDH Ephemeral	ECDHE	Yes	ECC with ephemeral keys (modern TLS)

TLS and Forward Secrecy:

TLS 1.2 (forward secrecy depends on cipher suite):

TLS_RSA_WITH_AES_256_GCM_SHA384: NO forward secrecy
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: YES forward secrecy

TLS 1.3 (all cipher suites have forward secrecy):

TLS_AES_256_GCM_SHA384: Requires ECDHE or DHE
No RSA key exchange allowed

Why Forward Secrecy Matters

Authenticated Key Exchange

Raw Diffie-Hellman is vulnerable to man-in-the-middle (MITM) attacks. It establishes a shared secret, but provides no assurance of who you're sharing it with.

The MITM Attack on Unauthenticated DH:

Converting Mermaid diagram...

Solutions: Authenticated Key Exchange

Several mechanisms authenticate DH exchanges:

1. Station-to-Station (STS) Protocol:

After DH exchange, both parties sign the transcript
Signatures prove identity and prevent MITM
Used in IKE (IPsec key exchange)

2. SIGn-and-MAc (SIGMA) Protocol:

Signs identity and DH values
MACs the messages with derived key
Basis for IKEv2

3. TLS Handshake:

Server signs its DH value with certificate private key
Client verifies signature using server's certificate
Optional client authentication via client certificates

4. PAKE (Password-Authenticated Key Exchange):

Uses a shared password to authenticate
Resistant to offline dictionary attacks
Examples: SRP, SPAKE2, OPAQUE

authenticated_dh.pseudo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Authenticated DH (TLS 1.3 style, simplified)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
CLIENT                                   SERVER
──────                                   ──────
Generate ephemeral a                     Has certificate with signing key
 
Compute A = g^a                          Generate ephemeral b
                                         Compute B = g^b
        ─────▶ ClientHello + A ─────▶
 
                                         signature = Sign(server_key, 
                                                         transcript || B)
 
        ◀─── ServerHello + B + Cert + signature ◀───
 
Verify certificate chain
Verify signature over B using Cert
 
      K = B^a = g^(ab)                   K = A^b = g^(ab)
 
★ AUTHENTICATED shared secret established! ★
 
Now:
- Client knows server is authentic (signature verified)
- Even MITM cannot forge signature without server's private key

Mutual Authentication

Key Exchange in TLS 1.3

TLS 1.3 represents the state of the art in authenticated key exchange for the web. Let's trace through its key exchange process.

TLS 1.3 Key Exchange Overview:

TLS 1.3 uses a simplified handshake that's both faster and more secure than TLS 1.2. Key exchange happens immediately, with encryption beginning after just one round trip.

Converting Mermaid diagram...

Key Schedule and Key Derivation:

TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) to derive multiple keys from the shared secret:

                    0
                    |
                    v
              [Early Secret]
                    |
          +--------+--------+
          |                 |
    [binder_key]      [client_early_traffic_secret]
                            |
                            v
                    (ECDH Secret)
                            |
                            v
              [Handshake Secret]
                    |
          +--------+--------+
          |                 |
[c_hs_traffic_secret] [s_hs_traffic_secret]
                            |
                            v
                     [Master Secret]
                            |
          +--------+--------+--------+
          |                 |        |
[c_ap_traffic_secret] [s_ap_traffic_secret] [resumption_secret]

Derived Keys:

Handshake secrets: Encrypt handshake messages after ServerHello
Application secrets: Encrypt application data
Resumption secret: Enables session resumption without full handshake

TLS 1.3 Supported Key Exchange Groups
Group	Security Level	Performance	Notes
x25519	~128 bits	Fastest	Preferred for most uses
secp256r1 (P-256)	~128 bits	Fast	NIST curve, widely supported
x448	~224 bits	Medium	Higher security than x25519
secp384r1 (P-384)	~192 bits	Medium	Government/enterprise
secp521r1 (P-521)	~256 bits	Slower	Highest ECC security
ffdhe2048	~112 bits	Slow	Finite field DH, legacy
ffdhe3072	~128 bits	Slow	Finite field DH, more secure

0-RTT: Speed with Tradeoffs

Practical Key Exchange

Let's see how key exchange is implemented in practice with code examples.

ECDH Key Exchange Examples:

ecdh_key_exchange.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
const crypto = require('crypto');
 
// Simulate Alice and Bob performing ECDH key exchange
 
// Alice generates her key pair
const alice = crypto.createECDH('prime256v1');  // P-256 curve
alice.generateKeys();
const alicePublicKey = alice.getPublicKey();
 
// Bob generates his key pair
const bob = crypto.createECDH('prime256v1');
bob.generateKeys();
const bobPublicKey = bob.getPublicKey();
 
// Exchange public keys (over network)
// Alice computes shared secret using Bob's public key
const aliceSharedSecret = alice.computeSecret(bobPublicKey);
 
// Bob computes shared secret using Alice's public key
const bobSharedSecret = bob.computeSecret(alicePublicKey);
 
// Verify they got the same shared secret
console.log('Alice shared secret:', aliceSharedSecret.toString('hex'));
console.log('Bob shared secret:  ', bobSharedSecret.toString('hex'));
console.log('Secrets match:', 
    aliceSharedSecret.equals(bobSharedSecret));
 
// Derive encryption key using HKDF
const derivedKey = crypto.hkdfSync(
    'sha256',
    aliceSharedSecret,
    Buffer.alloc(0),  // No salt for simplicity
    Buffer.from('encryption key'),
    32  // 256-bit key
);
console.log('Derived AES key:', derivedKey.toString('hex'));

Important Implementation Considerations:

Consideration	Best Practice
Curve selection	Use X25519 or P-256; avoid weak curves
Private key handling	Generate fresh for each session, securely delete after
Key derivation	Always use HKDF or similar KDF, never raw shared secret
Public key validation	Verify received point is on the curve
Side channels	Use constant-time implementations
Error handling	Don't leak information through error messages

Never Skip Key Derivation

Summary: Key Exchange Mastery

We've explored the fascinating world of key exchange protocols. Let's consolidate the key takeaways:

Key Takeaways

•Diffie-Hellman enables shared secrets over public channels — Using the discrete logarithm problem, two parties compute a shared secret that eavesdroppers cannot determine.
•ECDH is the modern standard — Elliptic curve DH provides equivalent security with smaller keys and faster operations.
•Ephemeral keys enable forward secrecy — By using fresh keys for each session and deleting them afterward, past sessions remain secure even if long-term keys are compromised.
•Authentication is essential — Raw DH is vulnerable to MITM attacks; signatures or certificates must authenticate the exchange.
•TLS 1.3 exemplifies best practices — Mandatory forward secrecy, authenticated key exchange, and modern cipher suites.
•Key derivation is mandatory — Raw shared secrets must be processed through KDFs before use as encryption keys.

What's Next:

Page Complete

4 / 5

Asymmetric Encryption - Page 4 of 5 | OneNoughtOne