Path: blob/main/foundations/05-discrete-log-diffie-hellman/sage/05c-diffie-hellman-key-exchange.ipynb
483 views
Notebook 05c: Diffie-Hellman Key Exchange
Module 05. The Discrete Logarithm and Diffie-Hellman
Motivating Question. Alice and Bob want to agree on a shared secret key, but they can only communicate over a public channel that Eve can monitor. Every message they send, Eve sees. How can they possibly end up with a shared secret that Eve does not know? Whitfield Diffie and Martin Hellman showed in 1976 that the discrete logarithm problem makes this possible.
Prerequisites. You should be comfortable with:
The discrete logarithm problem (notebook 05a)
Primitive roots and generators (notebook 05b)
Modular exponentiation (Module 01/04)
Learning objectives. By the end of this notebook you will be able to:
Describe the Diffie-Hellman protocol step by step.
Simulate a complete key exchange in SageMath.
Explain why the protocol is correct () and why Eve cannot easily compute the shared secret.
Identify the limitations of basic DH (no authentication, man-in-the-middle).
Understand parameter selection: safe primes and group choice.
1. The Protocol
The Diffie-Hellman key exchange has three phases:
Phase 1: Public Parameters
Alice and Bob publicly agree on:
A large prime
A generator of (or of a large prime-order subgroup)
Phase 2: Exchange
| Step | Alice | Public Channel | Bob |
|---|---|---|---|
| 1 | Picks secret | Picks secret | |
| 2 | Computes | ||
| 3 | Computes |
Phase 3: Shared Secret
| Alice computes | Bob computes |
|---|---|
Both arrive at the same value .
Checkpoint 1. Why does ? Write out the algebraic steps. (Answer: , using the commutativity of exponents in an abelian group.)
2. What Eve Sees
Eve observes on the public channel. To find the shared secret , she would need to either:
Recover from (solve the DLP), or
Recover from (solve the DLP), or
Compute directly from and without knowing or (the Computational Diffie-Hellman problem, covered in 05d).
All three are believed to be computationally infeasible for large primes.
Misconception alert. "DH sends the shared secret over the channel." No! The shared secret is never transmitted. Alice sends and Bob sends . Neither of these reveals (under the CDH assumption). The "magic" is that both parties can independently compute the same value.
3. Step-by-Step with Small Numbers
Let us trace a complete exchange with so we can verify every step by hand.
Checkpoint 2. Redo the exchange with . Compute , and by hand (use the power table from 05a if needed), then verify with SageMath.
4. Visualising the Key Space
Let us visualise what the possible shared secrets look like for a small prime. For each pair , the shared secret is .
5. Parameter Selection
For DH to be secure, the parameters must be chosen carefully:
| Parameter | Requirement | Why |
|---|---|---|
| Large (2048+ bits) | DLP difficulty scales with | |
| Preferably a safe prime | Limits subgroup attacks | |
| Generator of prime-order subgroup of order | DLP has no small-subgroup shortcuts | |
| Random, uniform in | Predictable exponents = broken DH |
Bridge from Module 04. Remember that in RSA, we needed and to be large primes. Here the requirement is similar but different: we need to be large and to have a large prime factor (ideally with prime). This constrains the structure of in a way that resists the Pohlig-Hellman attack (notebook 05f).
6. Man-in-the-Middle Attack
Basic DH provides no authentication. An active attacker (Mallory) can intercept and substitute her own values:
| Alice | Channel | Mallory | Channel | Bob |
|---|---|---|---|---|
| intercepts , sends | receives | |||
| receives | intercepts , sends |
Now Alice shares key with Mallory, and Bob shares key with Mallory. Mallory can decrypt, read, re-encrypt, and forward all messages.
Crypto foreshadowing. Real protocols solve this with authenticated DH:
TLS 1.3: the server signs its DH share with its certificate's private key.
Signal (X3DH): uses long-term identity keys to authenticate the DH exchange.
IKEv2 (IPsec): authenticates with pre-shared keys or certificates.
The DH exchange provides confidentiality; authentication is layered on top.
7. From Shared Secret to Encryption Key
The raw DH shared secret is a group element, not a uniform bitstring suitable as an encryption key. In practice, it is passed through a key derivation function (KDF) like HKDF:
This extracts the entropy into a fixed-length, pseudorandom key.
Checkpoint 3. Why can't Alice and Bob just use directly as an AES key? Think about two issues: (1) the value has bits but might not be uniformly distributed, and (2) AES needs exactly 128 or 256 bits.
8. Exercises
Exercise 1 (Worked): Complete DH Exchange
Problem. Perform a DH exchange with . Compute , and the shared secret.
Solution.
Alice:
Bob:
Both should give the same answer.
Exercise 2 (Guided): Eve's Brute-Force Attack
Problem. Given public values :
Solve the DLP to find Alice's secret (i.e., find such that ).
Use to compute the shared secret .
Verify by also solving for and checking .
Hint: Use discrete_log() or a brute-force loop.
Exercise 3 (Independent): Multi-Party DH
Problem. Can DH be extended to three parties (Alice, Bob, Charlie)?
Research or design a protocol where three parties arrive at a common shared secret using only public exchanges.
Implement it in SageMath with .
How many rounds of communication are needed? (Hint: it requires 2 rounds, not 1.)
Summary
| Concept | Key Fact |
|---|---|
| DH protocol | Alice sends , Bob sends ; both compute |
| Correctness | |
| Security | Relies on DLP/CDH hardness: Eve sees but cannot compute |
| No authentication | Vulnerable to man-in-the-middle without signatures or certificates |
| Parameters | Use safe primes and generator of order- subgroup |
| Key derivation | Hash through KDF before using as symmetric key |
We have built the DH protocol from scratch. But how hard is it really for Eve to compute from and ? The next notebook formalises this with the CDH and DDH hardness assumptions.