Diffie-Hellman Key Exchange: Cryptography Deep Dive

Introduction and Core Concepts

The diffie-hellman key exchange is one of the most foundational breakthroughs in modern cryptography, solving a problem that had puzzled cryptographers for centuries: how can two parties establish a shared secret over an insecure, public channel without ever having met before? Published in 1976 by Whitfield Diffie and Martin Hellman in their seminal paper "New Directions in Cryptography," this protocol introduced the concept of public-key cryptography and made secure communication over the internet possible at scale.

Before Diffie-Hellman, symmetric encryption required both parties to share a secret key in advance through a secure out-of-band channel, such as a courier or a prior meeting. This key distribution problem severely limited the scalability of encrypted communication. If you wanted to securely communicate with thousands of people, you needed thousands of pre-shared keys, securely exchanged. The diffie-hellman key exchange elegantly eliminates this requirement by allowing two parties, often called Alice and Bob, to jointly derive the same secret key while communicating only over a channel that an eavesdropper, Eve, can fully observe.

It is crucial to understand what Diffie-Hellman is and what it is not. It is a key exchange protocol, not an encryption algorithm. It does not encrypt messages itself; instead, it provides a secure method for two parties to agree on a symmetric key, which can then be used with a symmetric cipher like AES to encrypt subsequent communication. Its security relies on the computational hardness of the discrete logarithm problem, a one-way mathematical function that is easy to compute in one direction but believed to be infeasible to reverse for large numbers. Understanding this distinction is key to appreciating both its power and its limitations.

Why Diffie-Hellman Still Matters

In an era of TLS 1.3, VPNs, and end-to-end encrypted messaging, the principles of Diffie-Hellman are more relevant than ever. Every time you connect to a website via HTTPS, your browser likely performs a variant of the diffie-hellman key exchange to negotiate a session key with the server. Without it, e-commerce, online banking, and private communication as we know it would not exist. Its ability to provide perfect forward secrecy, ensuring that past communications remain secure even if a long-term key is compromised, has made ephemeral Diffie-Hellman the gold standard for modern secure protocols.

Furthermore, the conceptual framework introduced by Diffie and Hellman paved the way for all subsequent public-key cryptography, including RSA, ElGamal, and elliptic curve cryptography. Studying the diffie-hellman key exchange is therefore not just about learning one protocol; it is about understanding the mathematical paradigm shift that underpins the entire field of asymmetric cryptography and internet security.

How It Works

The elegance of the diffie-hellman key exchange lies in its use of modular arithmetic and the properties of exponentiation. The protocol operates in a finite cyclic group, most classically the multiplicative group of integers modulo a large prime p. The security depends on carefully chosen public parameters that are shared openly between all participants.

First, two public parameters are agreed upon and can be known to everyone, including an attacker: a large prime number p (the modulus) and a generator g (also called the base), which is typically a primitive root modulo p. These parameters do not need to be secret. In practice, they are standardized and often hard-coded into protocols. For example, the Internet Engineering Task Force (IETF) publishes standard groups with specific p and g values for TLS and IKE. The strength of the system depends entirely on the size of p and the secrecy of the private values generated by each party.

The exchange itself proceeds in four steps. Alice generates a private secret integer a, chosen randomly from the range [2, p-2], and keeps it secret. She then computes her public value A = g^a mod p and sends A to Bob over the public channel. Simultaneously, Bob generates his own private secret b and computes his public value B = g^b mod p, sending B to Alice. At this point, an eavesdropper has seen p, g, A, and B, but not a or b.

The Mathematical Magic of the Shared Secret

Once the public values are exchanged, each party can compute the same shared secret s. Alice computes s = B^a mod p, which is (g^b)^a mod p = g^(b*a) mod p. Bob computes s = A^b mod p, which is (g^a)^b mod p = g^(a*b) mod p. Due to the commutative property of exponentiation, both computations yield the identical value: g^(ab) mod p. This value s is the shared secret that can now be used as a symmetric key or, more commonly, passed through a key derivation function (KDF) to produce strong encryption keys.

An attacker who observes A and B would need to compute s = g^(ab) mod p. To do so, they would need to recover either a from A = g^a mod p or b from B = g^b mod p. This is precisely the discrete logarithm problem: given g, p, and g^a mod p, find a. For small primes, this is trivial, but for primes that are 2048 bits or larger, no efficient classical algorithm is known. The best known algorithms, such as the General Number Field Sieve, have sub-exponential but still super-polynomial time complexity, making the computation infeasible with current technology.

It is important to note that the raw shared secret s is not uniformly random and should never be used directly as an encryption key. It may have algebraic structure and biases. In all modern implementations, s is fed into a cryptographic hash function like HKDF (HMAC-based Key Derivation Function) with SHA-256 to produce a uniformly distributed, strong key suitable for AES or ChaCha20.

Implementation

Implementing the diffie-hellman key exchange correctly requires attention to parameter generation, secure random number generation, and proper key derivation. The following Python examples are for educational purposes and demonstrate the core logic. For production use, you should always use a vetted cryptographic library such as cryptography or PyCryptodome, which handles constant-time operations, safe primes, and side-channel protections.

The first example shows the fundamental Diffie-Hellman operations using Python's built-in pow function, which efficiently performs modular exponentiation using exponentiation by squaring.

# Basic Diffie-Hellman Key Exchange - Educational Implementation
import secrets
import hashlib

# Public parameters (in production, use 2048+ bit safe prime from RFC 7919)
# Small values used here for demonstration only
p = 23  # Prime modulus (DO NOT use small primes in production)
g = 5   # Generator (primitive root modulo p)

def generate_private_key(p):
    """Generate a cryptographically secure private key."""
    # Private key should be in range [2, p-2]
    # Use secrets module for cryptographically strong randomness
    return secrets.randbelow(p - 3) + 2

def generate_public_key(private_key, g, p):
    """Compute public key: A = g^a mod p"""
    return pow(g, private_key, p)

def compute_shared_secret(their_public, my_private, p):
    """Compute shared secret: s = B^a mod p"""
    return pow(their_public, my_private, p)

def derive_key(shared_secret):
    """Derive a 256-bit key from shared secret using SHA-256 KDF"""
    # Convert secret to bytes and hash it
    secret_bytes = str(shared_secret).encode('utf-8')
    return hashlib.sha256(secret_bytes).hexdigest()

# Alice's side
alice_private = generate_private_key(p)
alice_public = generate_public_key(alice_private, g, p)

# Bob's side
bob_private = generate_private_key(p)
bob_public = generate_public_key(bob_private, g, p)

# Exchange public keys over insecure channel
# ... alice_public sent to Bob, bob_public sent to Alice ...

# Both compute shared secret
alice_shared = compute_shared_secret(bob_public, alice_private, p)
bob_shared = compute_shared_secret(alice_public, bob_private, p)

print(f"Public parameters: p={p}, g={g}")
print(f"Alice public: {alice_public}, Bob public: {bob_public}")
print(f"Alice shared: {alice_shared}, Bob shared: {bob_shared}")
print(f"Keys match: {alice_shared == bob_shared}")
print(f"Derived AES key: {derive_key(alice_shared)}")

The second example demonstrates how to use a proper, standardized 2048-bit group from RFC 7919 and a production-grade library. This is the correct approach for any real-world system.

# Production-Grade Implementation using 'cryptography' library
# pip install cryptography
from cryptography.hazmat.primitives.asymmetric import dh
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.backends import default_backend

# Use a standardized 2048-bit MODP group (RFC 7919 Group 14)
# In practice, load parameters from RFC 7919 or generate with care
parameters = dh.generate_parameters(generator=2, key_size=2048, backend=default_backend())

# --- Alice generates key pair ---
alice_private_key = parameters.generate_private_key()
alice_public_key = alice_private_key.public_key()

# --- Bob generates key pair ---
bob_private_key = parameters.generate_private_key()
bob_public_key = bob_private_key.public_key()

# --- Key Exchange ---
# Alice computes shared secret using Bob's public key
alice_shared_key = alice_private_key.exchange(bob_public_key)

# Bob computes shared secret using Alice's public key
bob_shared_key = bob_private_key.exchange(alice_public_key)

assert alice_shared_key == bob_shared_key

# --- Key Derivation with HKDF ---
# Never use raw shared secret directly; derive a strong key
derived_key_alice = HKDF(
    algorithm=hashes.SHA256(),
    length=32,  # 256-bit key for AES-256
    salt=None,
    info=b'handshake data',
    backend=default_backend()
).derive(alice_shared_key)

print(f"Derived 256-bit key (hex): {derived_key_alice.hex()}")
print(f"Shared secrets match: {alice_shared_key == bob_shared_key}")

For elliptic curve Diffie-Hellman (ECDH), which is preferred today due to smaller keys and faster computation, the logic is similar but operates on elliptic curve points rather than modular exponentiation.

# Elliptic Curve Diffie-Hellman (ECDH) - Modern Preferred Variant
# pip install cryptography
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.backends import default_backend

# Use a standard curve like SECP256R1 (NIST P-256)
curve = ec.SECP256R1()

# Alice generates private/public key pair on the curve
alice_private = ec.generate_private_key(curve, default_backend())
alice_public = alice_private.public_key()

# Bob generates private/public key pair
bob_private = ec.generate_private_key(curve, default_backend())
bob_public = bob_private.public_key()

# Exchange and compute shared secret
alice_shared = alice_private.exchange(ec.ECDH(), bob_public)
bob_shared = bob_private.exchange(ec.ECDH(), alice_public)

assert alice_shared == bob_shared

# Derive symmetric key
derived_key = HKDF(
    algorithm=hashes.SHA256(),
    length=32,
    salt=None,
    info=b'ecdh handshake',
    backend=default_backend()
).derive(alice_shared)

print(f"ECDH derived key: {derived_key.hex()}")
print(f"ECDH key length: {len(derived_key) * 8} bits")

A common pitfall is improper validation of public keys. Without validation, an attacker can send malicious public values to force the shared secret to a small, predictable subset. Always validate that the received public key is within the correct range and is not 0, 1, or p-1.

# Secure Public Key Validation (Critical for Security)
def validate_public_key(public_key, p):
    """Validate Diffie-Hellman public key to prevent small subgroup attacks."""
    # Check range: must be in [2, p-2]
    if public_key < 2 or public_key > p - 2:
        raise ValueError("Public key out of valid range")

    # Check not in small subgroup (for safe primes, check != 1 and != p-1)
    if public_key == 1 or public_key == p - 1:
        raise ValueError("Public key in small subgroup")

    # For safe primes where p = 2q + 1, verify public_key^q mod p != 1
    # This ensures the key is in the large prime-order subgroup
    q = (p - 1) // 2
    if pow(public_key, q, p) == 1:
        # This check depends on group structure; consult standard
        pass

    return True

# Example usage during key exchange
try:
    validate_public_key(bob_public, p)
    shared = compute_shared_secret(bob_public, alice_private, p)
except ValueError as e:
    print(f"Key validation failed: {e}")
    # Abort connection - do not compute shared secret

Step-by-Step Example

To make the abstract mathematics concrete, let us walk through a complete diffie-hellman key exchange with small numbers that can be verified by hand. While these numbers are insecurely small for real use, they perfectly illustrate the mechanism. We will use the public parameters p = 23 and g = 5. The prime 23 is small enough to compute manually, and 5 is a primitive root modulo 23, meaning its powers generate all values from 1 to 22.

Step 1: Private Key Generation. Alice secretly chooses a private key a = 6. She keeps this number hidden and never transmits it. Bob secretly chooses a private key b = 15. These choices are random and independent. The security of the entire exchange depends on these values remaining secret.

Step 2: Public Key Computation. Alice computes her public key A = g^a mod p = 5^6 mod 23. Calculating 5^6 = 15625. Then 15625 mod 23 = 8. So Alice's public key is A = 8. Bob computes his public key B = g^b mod p = 5^15 mod 23. Computing 5^15 mod 23 efficiently using modular exponentiation yields 19. So Bob's public key is B = 19. Alice sends A=8 to Bob, and Bob sends B=19 to Alice over the public channel. An eavesdropper now knows p=23, g=5, A=8, and B=19.

Computing and Verifying the Shared Secret

Step 3: Shared Secret Derivation. Alice receives B=19 and computes s = B^a mod p = 19^6 mod 23. 19^6 mod 23 = 2. Bob receives A=8 and computes s = A^b mod p = 8^15 mod 23. 8^15 mod 23 = 2. Both parties have arrived at the same shared secret, s = 2, without ever transmitting the secret itself. They can now hash this value to create a 256-bit key for AES encryption.

Step 4: Why the Eavesdropper Fails. Eve, who observed all public traffic, knows p, g, A, and B. To find s, she would need to solve the discrete logarithm problem. She would need to find a such that 5^a mod 23 = 8. For p=23, she could brute-force this by trying all values, but for a 2048-bit prime, there are approximately 10^616 possible values, making brute force impossible. The best known attack would take longer than the age of the universe on current supercomputers.

This toy example reveals a critical nuance: the shared secret s=2 is small and predictable in this tiny group. In a real implementation with a 2048-bit prime, s will be a 2048-bit number with enormous entropy. The example also highlights why g must be a primitive root or at least generate a large subgroup. If g generated only a small subgroup, the number of possible shared secrets would be small, and Eve could brute-force s directly even without solving the discrete log.

Complexity Analysis

The performance and security of the diffie-hellman key exchange are governed by the complexity of modular exponentiation and the hardness of the discrete logarithm problem. Understanding these complexities is essential for choosing appropriate key sizes and predicting system performance.

The dominant operation for legitimate parties is modular exponentiation: computing g^a mod p. This is performed using the exponentiation by squaring algorithm, also known as binary exponentiation. This algorithm reduces the number of multiplications from O(a) to O(log a). Since a is typically a number up to p in size, and p is a k-bit number, the number of modular multiplications is O(k). Each modular multiplication of k-bit numbers using naive algorithms costs O(k^2), though faster algorithms like Karatsuba or FFT-based multiplication can reduce this. Overall, the time complexity for one exponentiation is O(k^3) with schoolbook multiplication, or O(k^2 log k) with more advanced methods. In Big O terms, this is polynomial time and very efficient for the legitimate participants.

For an attacker, the complexity is entirely different. The naive brute-force attack to solve the discrete logarithm by trying every possible private key has time complexity O(p) = O(2^k), which is exponential in the bit-length k and completely infeasible for k >= 2048. More sophisticated attacks like Baby-step Giant-step have time and space complexity O(sqrt(p)) = O(2^(k/2)), which is still exponential. The most efficient classical attack against the finite-field Diffie-Hellman is the General Number Field Sieve (GNFS) for discrete logarithms, which has sub-exponential complexity approximately O(exp((64/9)^(1/3) * (ln p)^(1/3) * (ln ln p)^(2/3))). While faster than exponential, this is still super-polynomial and infeasible for large p.

Space complexity for the legitimate parties is minimal, O(k) to store the k-bit numbers p, g, private keys, and shared secret. This makes Diffie-Hellman suitable for constrained devices like smart cards and IoT sensors when using elliptic curve variants.

Where k is the bit-length of prime p. For ECDH with a k-bit curve, legitimate operations are O(k^2) to O(k^3) but provide equivalent security to much larger finite-field DH, which is why ECDH with k=256 is considered as secure as finite-field DH with k=3072.

Variations and Optimizations

Classic finite-field Diffie-Hellman, while secure when implemented correctly, has been largely superseded by more efficient and robust variants. The most important evolution is the move to elliptic curves and the adoption of ephemeral key exchange for forward secrecy.

Elliptic Curve Diffie-Hellman (ECDH) is the most significant optimization. Instead of operating in the multiplicative group modulo a prime, ECDH operates on the group of points on an elliptic curve. The discrete logarithm problem on elliptic curves (ECDLP) is believed to be much harder than in finite fields, meaning a 256-bit elliptic curve provides roughly the same security as a 3072-bit finite-field Diffie-Hellman group. This results in dramatically faster computations, smaller keys, lower bandwidth, and reduced power consumption, making ECDH ideal for mobile devices, TLS, and IoT. Curves like Curve25519 and NIST P-256 are now the de facto standards.

Ephemeral Diffie-Hellman (DHE and ECDHE) addresses a critical security property: perfect forward secrecy (PFS). In static Diffie-Hellman, the same long-term key pair is reused for many sessions. If that long-term private key is ever compromised, all past session keys derived from it can be decrypted. Ephemeral variants generate a new, temporary key pair for every single connection or session and discard the private key immediately after use. Even if the server's long-term signing key is stolen, past communications remain secure because the ephemeral private keys no longer exist. TLS 1.3 mandates ephemeral key exchange and has removed support for static RSA and static DH entirely for this reason.

Other Notable Variants

Authenticated Diffie-Hellman combines the key exchange with authentication to prevent man-in-the-middle attacks. Raw Diffie-Hellman is unauthenticated: Eve can intercept A and B and substitute her own values, establishing separate shared secrets with Alice and Bob. Protocols like Station-to-Station (STS) and the handshake in TLS solve this by signing the exchanged public values with long-term identity keys (RSA or ECDSA). This ensures that Alice is really talking to Bob and not an impostor.

Other optimizations include X25519, a specific ECDH implementation using Curve25519 designed by Daniel J. Bernstein. It is notable for its speed, constant-time implementation that resists side-channel attacks, and its use of a Montgomery curve that allows for very efficient and secure computation. Triple Diffie-Hellman (3DH) and Extended Triple Diffie-Hellman (X3DH), used in the Signal Protocol, combine multiple Diffie-Hellman exchanges to provide mutual authentication and resilience against key compromise.

Real-World Applications

The diffie-hellman key exchange is not a theoretical curiosity; it is a workhorse of the modern internet, embedded in nearly every protocol that requires secure communication. Its most visible application is in securing web traffic.

In Transport Layer Security (TLS), which secures HTTPS, Diffie-Hellman is the primary mechanism for establishing session keys. When you navigate to https://example.com, your browser and the web server perform an ECDHE handshake. The server presents its certificate, both sides exchange ephemeral ECDH public keys, derive a shared secret, and use it to encrypt the entire HTTP session with AES-GCM or ChaCha20-Poly1305. According to measurements from Cloudflare and Google, over 90% of TLS connections today use ECDHE, providing forward secrecy for billions of daily web transactions. Web servers like Nginx, Apache, and databases that expose TLS endpoints all rely on this.

Beyond the web, Diffie-Hellman secures network infrastructure at multiple layers. Virtual Private Networks (VPNs) using IPsec and its key management protocol IKEv2 use Diffie-Hellman to establish security associations between gateways and clients. The IKEv2 handshake performs a Diffie-Hellman exchange to derive keys that encrypt all subsequent VPN traffic, allowing remote employees to securely access corporate networks. Similarly, SSH (Secure Shell), used by system administrators to manage servers and databases, uses ECDH to negotiate encryption keys for every interactive session, ensuring that credentials and commands are never sent in plaintext.

Messaging, Email, and Data Protection

End-to-end encrypted messaging applications are perhaps the most demanding users of Diffie-Hellman. The Signal Protocol, which underpins Signal, WhatsApp, and Facebook Messenger's secret conversations, uses a sophisticated variant called X3DH (Extended Triple Diffie-Hellman) for initial key agreement and the Double Ratchet algorithm, which continuously performs new Diffie-Hellman exchanges to achieve post-compromise security. Each message is encrypted with a new key derived from a fresh DH exchange, so even if one message key is compromised, future and past messages remain secure.

In the realm of data storage and communication, protocols like PGP/GPG for email encryption, DNSSEC for securing DNS lookups, and even secure database replication often use Diffie-Hellman for key establishment. For example, when a PostgreSQL or MySQL database replicates data to a standby over TLS, the replication stream is protected by an ephemeral Diffie-Hellman exchange. File-sharing protocols and peer-to-peer networks also use it to establish encrypted channels between peers who have never met.

Comparison with Alternatives

While the diffie-hellman key exchange was the first public-key key exchange protocol, it is not the only one. Different protocols offer different trade-offs in terms of authentication, performance, and resistance to quantum attacks. Choosing the right mechanism depends on the specific security requirements and constraints of the system.

RSA Key Exchange was historically the most common alternative in TLS. In RSA key exchange, the client generates a random pre-master secret, encrypts it with the server's RSA public key, and sends it to the server. The server decrypts it with its private key. This is simpler than Diffie-Hellman and requires only one round trip, but it has a fatal flaw: it does not provide forward secrecy. If the server's RSA private key is ever compromised, an attacker who recorded all past traffic can decrypt every session. This is why TLS 1.3 deprecated RSA key exchange entirely in favor of (EC)DHE.

Elliptic Curve Diffie-Hellman (ECDH) is not so much an alternative as a direct, superior successor to finite-field DH. It provides the same functionality with vastly smaller keys and faster operations. For new systems, ECDH (specifically X25519 or P-256) should always be preferred over classic finite-field DHE unless there is a specific legacy compatibility requirement. The security per bit is much higher, and implementations are less prone to subtle parameter pitfalls.

The most important emerging alternative is post-quantum key encapsulation mechanisms (KEMs) like CRYSTALS-Kyber (now standardized as ML-KEM). Diffie-Hellman and ECDH are both vulnerable to Shor's algorithm, which can solve the discrete logarithm problem efficiently on a sufficiently large quantum computer. While such computers do not yet exist at the required scale, the threat of "harvest now, decrypt later" attacks, where adversaries record encrypted traffic today to decrypt later with a quantum computer, is driving migration to post-quantum cryptography. Kyber is based on the hardness of lattice problems, which are believed to be resistant to quantum attacks. Hybrid deployments that combine ECDH with Kyber are currently being standardized for TLS to provide security against both classical and quantum adversaries.

Common Mistakes and Best Practices

Despite its mathematical elegance, the diffie-hellman key exchange is notoriously difficult to implement securely. Many high-profile vulnerabilities, such as Logjam and WeakDH, have stemmed from implementation flaws rather than breaks in the underlying mathematics. Avoiding these pitfalls requires strict adherence to modern best practices.

The most common and dangerous mistake is using weak or standardized small parameters. The Logjam attack in 2015 showed that many servers used the same 512-bit or 1024-bit prime for Diffie-Hellman. An attacker could perform a massive precomputation for that single prime and then quickly break any connection using it. Never use primes smaller than 2048 bits for finite-field DH, and ideally use 3072 bits. Better yet, use ECDH with Curve25519 or P-256, which avoids prime selection issues entirely. Always use safe primes where p = 2q + 1 with q also prime, and use standardized groups from RFC 7919 (Groups 14-21) if you must use finite-field DH.

A second critical mistake is failing to authenticate the exchange, leaving it vulnerable to a man-in-the-middle (MITM) attack. Raw Diffie-Hellman provides no authentication; an active attacker can intercept Alice's public key A, replace it with her own A', intercept Bob's B and replace it with B', and establish two separate shared secrets, one with Alice and one with Bob, relaying and reading all traffic. This is not a theoretical concern; it is trivial to execute on an unauthenticated channel. Always combine Diffie-Hellman with authentication, typically by signing the public keys with long-term identity keys (e.g., ECDSA or RSA signatures) as done in TLS and STS. Never use unauthenticated DH for anything requiring security.

Implementation Pitfalls to Avoid

Other frequent errors include reusing private keys, failing to validate public keys, and using the raw shared secret directly. Reusing an ephemeral private key across multiple sessions destroys forward secrecy and can leak information if the random number generator is flawed. Generate a fresh, cryptographically secure random private key for every exchange using a proper CSPRNG like secrets in Python or /dev/urandom. Failing to validate that the received public key is in the correct subgroup can enable small subgroup attacks, where an attacker forces the shared secret into a small set of predictable values. Always validate that the received public value is in the range [2, p-2] and not in a small subgroup.

Finally, never use the raw shared secret s as an encryption key. The shared secret is not uniformly random and may have leading zeros or other structure. Always pass it through a strong Key Derivation Function like HKDF with SHA-256 or SHA-384, including context information such as the handshake transcript. For production systems, follow these best practices: prefer ECDHE with X25519, use TLS 1.3 which enforces correct usage, rely on well-audited libraries instead of rolling your own implementation, and ensure your random number generator is properly seeded and non-blocking.

Interview Questions

Understanding the diffie-hellman key exchange is a common requirement for interviews in security engineering, backend development, and cryptography roles. The following questions test both conceptual understanding and practical awareness.

1. Explain the Diffie-Hellman key exchange to a non-expert. What problem does it solve?

Answer: Use the paint-mixing analogy. Imagine Alice and Bob want to agree on a secret paint color over a public phone line. They first publicly agree on a common base color (yellow, representing p and g). Alice secretly mixes in her private color (red) and sends the resulting mixture (orange) to Bob. Bob secretly mixes in his private color (blue) and sends his mixture (green) to Alice. Alice then mixes her private red into Bob's green mixture, and Bob mixes his private blue into Alice's orange mixture. Both end up with the same final brown color (the shared secret), while an eavesdropper who only saw the orange and green mixtures cannot easily unmix them to find the final color. This solves the key distribution problem: establishing a shared secret without a prior secure channel, enabling secure communication over insecure networks like the internet.

2. Is Diffie-Hellman secure against a man-in-the-middle attack? If not, how do you fix it?

Answer: No, vanilla Diffie-Hellman is completely insecure against an active man-in-the-middle attacker. Since the public keys are not authenticated, an attacker can intercept and replace them, establishing separate shared secrets with each party and transparently decrypting and re-encrypting all traffic. The fix is to add authentication. This is typically done by having each party sign their Diffie-Hellman public value with their long-term identity private key (e.g., using RSA or ECDSA signatures) and verifying the signature with the peer's certificate. Protocols like Station-to-Station (STS) and TLS do exactly this: the DH exchange provides confidentiality and forward secrecy, while the signatures provide authentication. Without authentication, DH should only be used where MITM is not a concern, which is rare.

3. What is the difference between DHE, ECDHE, and static DH? Why does TLS 1.3 prefer ECDHE?

Answer: Static DH uses a long-term, fixed key pair for the server (and sometimes the client). DHE (Ephemeral Diffie-Hellman) generates a new, temporary key pair for every handshake and discards it afterward. ECDHE is the ephemeral variant using elliptic curves. The critical difference is forward secrecy: with static DH, compromise of the long-term private key allows decryption of all past sessions. With DHE/ECDHE, each session uses a unique key that is deleted, so past sessions remain secure even if the long-term signing key is later stolen. TLS 1.3 prefers ECDHE because it provides forward secrecy, is much faster and more efficient than finite-field DHE (256-bit ECDH vs 3072-bit DHE for equivalent security), uses smaller messages, and has fewer parameter pitfalls. TLS 1.3 actually removed support for static key exchange entirely.

4. What is the discrete logarithm problem and why does it matter for Diffie-Hellman? How large should p be today?

Answer: The discrete logarithm problem is: given a prime p, generator g, and value A = g^a mod p, find the exponent a. It is easy to compute A from a and g (modular exponentiation is polynomial time), but believed to be hard to compute a from A for large p (no efficient classical algorithm is known). Diffie-Hellman's security relies entirely on this hardness; if an attacker can solve the discrete log, they can recover the private keys a or b from the public values A or B and compute the shared secret. For finite-field DH today, p should be at least 2048 bits, with 3072 bits recommended for long-term security (providing ~128 bits of security). For ECDH, a 256-bit curve like P-256 or Curve25519 provides equivalent security with much better performance. Anything smaller, like 1024-bit p, is considered breakable by well-funded attackers due to the Logjam precomputation attack.

5. You need to implement Diffie-Hellman. Would you write your own modular exponentiation, and what library would you use?

Answer: No, you should never implement your own cryptographic primitives for production. You should use a well-audited, constant-time library that handles side-channel resistance, secure random generation, and parameter validation. In Python, use the cryptography library's dh or ec modules; in Go, use crypto/ecdh; in Java, use JCA with BouncyCastle. The library will use standardized groups (RFC 7919 for finite-field, or Curve25519/P-256 for ECDH), perform public key validation, and use HKDF for key derivation. Emphasize that the raw pow(g, a, p) approach is only for learning, and production code must handle validation, authentication, and proper KDF usage, and should prefer ECDHE with X25519 for modern applications.