Key Exchange

Every construction in Chapters 1 and 2 assumes a key the parties already share. Key exchange removes that assumption: Alice and Bob each want the same key $k$. The only communication channel available is public, while an adversary watches every message.

The adversary controls the channel, so she can read, reorder, drop and inject messages. Every protocol in this chapter is scored against one checklist of four items:

• Agreement: Alice and Bob output the same key. Each names the other as the peer of the session.
• Secrecy: the key is indistinguishable from a random string to the adversary.
• Authentication: the peer each party names is the peer actually on the other side of the exchange.
• Key confirmation: each party holds evidence that the peer computed the same key.

Authentication is the item most first attempts get wrong. Sections 2 to 9 and section 14 reuse this list for every protocol they present.

The chapter treats three adversaries in increasing strength. A passive eavesdropper only reads the transcript, and Diffie-Hellman resists her (section 2). An active adversary also rewrites messages, which is the setting of authenticated key exchange (sections 3 to 9). A quantum computer breaks the discrete-logarithm assumption under both, and Chapter 4 covers the post-quantum replacement.

The standard intuition is paint mixing. Alice and Bob start from the same public yellow paint. Alice stirs in a private red and Bob a private blue, then they swap pots. Each adds their own private color to the pot they received, and both arrive at the same final color. An eavesdropper who saw the two swapped pots cannot separate mixed paint back into its ingredients. The number-theoretic protocol replaces unmixing paint with a hard computation.

Take the prime $p = 23$ and the generator $g = 5$. Alice picks the secret $a = 4$ and sends $A = g^{a} \bmod p = 5^{4} \bmod 23 = 4$. Bob picks the secret $b = 3$ and sends $B = g^{b} \bmod p = 5^{3} \bmod 23 = 10$. Both then compute the shared secret

$$K_{\text{Alice}} = B^{a} \bmod p = 10^{4} \bmod 23 = 18, \qquad K_{\text{Bob}} = A^{b} \bmod p = 4^{3} \bmod 23 = 18.$$

Both hold $18$. Every value that crossed the channel is public. What each party can see:

At this toy size Eve can try every exponent. Protocol groups make that search infeasible. The general protocol runs in a cyclic group $\mathbb{G}$ of prime order $q$ with generator $g$, for example a prime-order subgroup of $\Z_p^{*}$ with $q \mid p-1$. Alice picks $x \getsr \Z_q$ and sends $X = g^x$; Bob picks $y \getsr \Z_q$ and sends $Y = g^y$; both compute

$$K = Y^x = X^y = g^{xy}.$$

Security against a passive adversary follows from the Decisional Diffie-Hellman (DDH) assumption. If the triple $(g^x, g^y, g^{xy})$ is indistinguishable from $(g^x, g^y, g^z)$ for fresh $z \getsr \Z_q$, the public transcript gives no way to tell the session key from a random group element.

Against the section 1 checklist, agreement holds because both parties compute $g^{xy}$. Secrecy holds against a passive eavesdropper under DDH. Authentication and key confirmation are absent, since nothing in the transcript names a peer.

The protocol keeps no long-term secret: $x$ and $y$ are used once and erased. That erasure gives perfect forward secrecy: once the session key is destroyed there is no record from which it can be recovered, so a later compromise of long-term keys cannot decrypt past sessions that used no long-term keys. One caveat applies once authentication is added: ephemeral Diffie-Hellman gives forward secrecy only when the surrounding authenticated protocol does not rest on a recoverable static DH secret. This is one reason ephemeral Diffie-Hellman remains in TLS 1.3.

Common mistake. Forward secrecy protects keys stored on disk. The guarantee is that each session's key-exchange secrets are erased after use: an attacker who records ciphertext today and steals the server's long-term key tomorrow still cannot decrypt the recording.

Group size is a real parameter choice. Logjam precomputed a 512-bit prime in about a week on many cores, after which individual discrete logs fell in about a minute, and a 1024-bit precomputation is estimated near $100M. Current recommendations are elliptic-curve groups, or classical groups of at least 2048 bits.

Worked number. An X25519 public key is 32 bytes and gives about 128 bits of security: brute force needs roughly $2^{128}$ curve operations. Finite-field Diffie-Hellman needs a 3072-bit prime, a 384-byte modulus on the wire, for a comparable margin.

Because the public values $g^x$ and $g^y$ carry no identity, an active adversary can replace each of them with one of her own. Eve picks $x', y' \getsr \Z_q$. When Alice sends $g^x$, Eve forwards $g^{y'}$ to Bob; when Bob sends $g^y$, Eve forwards $g^{x'}$ to Alice. Alice then computes $(g^{y'})^x = g^{xy'}$, which Eve also computes as $(g^x)^{y'}$. Bob computes $(g^{x'})^y = g^{x'y}$, which Eve computes as $(g^y)^{x'}$. Eve shares one key with Alice and another with Bob, and neither party sees anything unusual. She decrypts every subsequent message, reads or modifies it, and re-encrypts it toward the other side.

With the lab preset $p = 29$ the two keys are $27$ and $23$, while the honest key $16$ is never established. On the checklist, the attack breaks authentication and agreement at once: each party names the wrong peer. The two outputs differ.

What went wrong. Logjam (2015) applied this idea to TLS: a man in the middle rewrote the handshake to force weak 512-bit Diffie-Hellman parameters and recovered the session keys. The lesson is that a protocol must authenticate its own negotiation, so such rewrites fail.

Slide 6 states the fix: authenticated messages. Long-term authentication keys (master keys) sign or tag the exchange. The session key is the fresh output of it. Station-to-station, covered in section 7, is the classic authenticated repair. Each party signs the two public Diffie-Hellman values and encrypts the signature under the shared key itself.

Authenticated key exchange establishes a common secret with authentication attached. The parties hold previously established authentication keys, called master keys. Slide 7 lists the requirements in the vocabulary of the section 1 checklist:

• Secrecy: the session key is indistinguishable from a random string.
• Authentication: each party verifies the other's identity (mutual authentication).
• Agreement: both parties agree on who the peers of the session are, called consistency on the slide.

The first attempt signs the ephemeral public value alone. Alice sends $A, X, S(sk_A, X)$ and Bob sends $B, Y, S(sk_B, Y)$, after which they compute $K = Y^x = X^y$. Replay breaks it. If Eve ever obtains a triple $(x, g^x, S(sk_A, X))$, she sends it to Bob and impersonates Alice without learning $sk_A$, so ephemeral leakage turns into long-term impersonation and the attempt fails authentication.

The second attempt signs the whole transcript. Alice sends $A, X$; Bob replies with $B, Y, S(sk_B, X \| Y)$; Alice finishes with $S(sk_A, X \| Y)$. The signatures cover both public values, so replay of a single value no longer works.

The identity-misbinding attack breaks it anyway. Eve holds her own signing key $sk_E$ and runs two parallel sessions, relaying Alice's public value into Bob's session and Bob's reply back into Alice's.

The signed string $X \| Y$ is the same in both runs, so both signatures verify and the identities come out misbound. Alice accepts a key as shared with Bob, while Bob accepts the same key as shared with Eve. Eve never learns $K$; Bob simply attributes to Eve whatever Alice sends under that key. On the checklist, secrecy and agreement on the key value survive, and authentication is the item that fails.

What went wrong. The Triple Handshake attack (2014) showed the same danger in TLS: three sessions ended up sharing one master secret while disagreeing about the peer. TLS 1.3 hashes the whole handshake transcript into every derived key, so mismatched sessions derive different keys.

The repair is to include the peer identity under the signature. Alice sends $A, X$; Bob replies with

$$B, Y, S(sk_B, X \mid Y \mid A),$$

and Alice finishes with $S(sk_A, X \mid Y \mid B)$. The session key is then derived with the identities inside the hash:

$$K = Y^x = X^y, \qquad k = \Hash(A \mid B \mid X \mid Y \mid K).$$

Eve cannot forge $S(sk_E, X \mid Y \mid A)$ for Alice's identity, because she does not hold $sk_A$. A parallel session under Eve's identity produces a different signed string, so the misbinding run fails at verification. The slides state that this protocol avoids the previous attack and can be proven secure.

One naming note. The slides call the protocol ISO 9796 and the syllabus prints ISO 9697. The standard family for entity authentication with public keys is ISO/IEC 9798-3, which describes this mechanism.

The Canetti-Krawczyk model gives a security definition for key exchange protocols in the setting where they are deployed. The desiderata on slide 12:

• Match intuition about attacker capabilities and secrecy.
• Reject bad protocols.
• Accept good ones.
• Ensure the security of applications built on the session key, including composition.

The setting is a two-party protocol run in a multi-party world. Multiple executions run concurrently. Each run at a party is a session named $(A, s_A)$ or $(B, s_B)$, where $B$ is the intended peer of Alice's session. The session id is $(A, s_A, B, s_B)$, and two sessions with corresponding names, such as $(A, s_A, B, s_B)$ and $(B, s_B, A, s_A)$, are matching. A completed session outputs its session id and its session key.

The adversary controls every unauthenticated channel. She monitors, modifies and schedules traffic, and interleaves sessions at will. Beyond network control she has two query types, and exposure is defined through them.

A session is exposed if its owner was corrupted or if the adversary issued a learning query for it.

The definition catches the known failures. Impersonation breaks it, because an adversary who impersonates Bob without corrupting him learns a key for an unexposed session. Session independence is required, because the adversary must not break one session from the key of another. Identity misbinding breaks it through the test query: if Eve forces two non-matching sessions with outputs $(A, B, K)$ and $(B, E, K)$, she selects one as the test session, exposes the other and compares keys.

CK analyzes protocols directly; authenticators give a modular route. Start in an idealized model where channels are authenticated and the adversary is passive everywhere else, so plain Diffie-Hellman is trivially secure. An authenticator is a protocol compiler that turns a protocol secure in the authenticated model into one secure in the unauthenticated model.

Signature Authenticator

The signature authenticator sends $A, M$, then $B, N$, then $A, S(sk_A, M \mid N \mid B)$. The nonce $N$ blocks replay. The guarantee is that if Bob believes he received $M$ from Alice, then Alice sent $M$ to Bob. The slides note that this authenticator implies CK security of the ISO 9796 protocol.

Encryption Authenticator

The encryption authenticator replaces the signature. Bob sends $B, \Enc(pk_A, k_B)$ for a fresh random key $k_B$, and Alice replies with $M, T(k_B, M \| B)$. Only Alice can decrypt the ciphertext, so a valid tag convinces Bob that Alice participated. The first message of the ideal protocol can be dropped in this compilation.

What went wrong. In 1998 Daniel Bleichenbacher showed that a server answering differently for malformed RSA padding becomes an oracle that recovers the transported secret. The attack plagued RSA key transport until TLS 1.3 removed it.

SKEME

SKEME, used in IKEv1 (version 1 of the Internet Key Exchange protocol), applies the encryption authenticator to Diffie-Hellman. The parties exchange $X = g^x$ and $Y = g^y$, encrypt random keys $k_A$ and $k_B$ under each other's public keys, tag the exchanged values with those keys, and derive $k = \Hash(A \mid B \mid X \mid Y \mid K)$ from the Diffie-Hellman value.

Identity protection is a design pressure on IKE. Hiding identities matters against probing attacks and for location privacy of roaming users, and typically only one identity can be hidden against an active adversary. SKEME with encrypted identities does this, at the cost of requiring Alice to know Bob's public key beforehand.

STS

The station-to-station protocol takes another route: encrypt the identity and a signature under the Diffie-Hellman key $K$ itself, proving possession of $K$. The slides show that STS is insecure if Eve can register $pk_A$ as her own key, at least in the variant where the identity is in the clear. Replacing signatures with Message Authentication Codes (MACs) under $K$ still needs the key bound to the peer identities. That requirement leads directly to SIGMA.

SIGMA keeps the Diffie-Hellman exchange and changes what gets signed. In the basic version, Bob sends $B, Y, S(sk_B, X \mid Y), T(k', B)$ and Alice replies with $S(sk_A, X \mid Y), T(k', A)$. The signature covers the two public values, while the identity itself is tagged with a separate key $k'$ derived from $K$. The session key is again $k = \Hash(A \mid B \mid X \mid Y \mid K)$.

SIGMA satisfies every item in the section 1 checklist. The signatures over $X \mid Y$ authenticate the peers against an active adversary, the tags $T(k', A)$ and $T(k', B)$ confirm that the peer holds a key derived from $K$. The identities inside the final hash keep the two sides agreeing on one session.

SIGMA-I protects the initiator. Both identities are encrypted under a further derived key $k''$. Bob's identity is protected against passive attackers, and Alice's identity is protected against active attackers. SIGMA-R reverses the order so that Bob does not reveal his identity before checking who is talking to him; Bob's identity is protected against active attackers and Alice's against passive attackers.

The slides caution that the description is simplified and omits context and negotiation data. SIGMA can be proved secure in the CK model, although no modular proof through authenticators is known. It is used in IPsec (Internet Protocol security) and appears inside TLS 1.3 (Transport Layer Security; section 14).

Although the ISO 9796 style works, every exchange carries signatures and certificates. Implicit authentication asks whether authentication can be obtained without sending any signature or tag: the ability to compute the session key itself serves as proof of identity. The cost questions are communication, computation and the resulting security level.

The slides first discard two natural attempts. Taking $k = \Hash(g^{ay}, g^{xy})$ lets an adversary who learns one session key derive keys for other sessions. Taking $k = \Hash(g^{ay}, g^{xy}, g^x, g^y)$ lets an adversary who knows Bob's long-term $b$ impersonate Alice to Bob. The target is security unless the pair $(a, x)$ or the pair $(b, y)$ leaks.

MQV starts from the idea $K = g^{(a+x)(b+y)}$, with long-term keys $A = g^a$, $B = g^b$ and ephemeral values $X = g^x$, $Y = g^y$. The basic form is insecure: Eve can send a substituted value $X^{*} = g^{x^{*}} / A$. The key collapses to a value Bob also computes, so Eve can force matching keys across sessions. The repair is to use

$$K = g^{(x + da)(y + eb)},$$

where $d$ and $e$ are values Eve cannot control together with the corresponding public values.

Hashed MQV instantiates the repair with hashes. Alice computes $d = \Hash(X \| \mathrm{Bob})$ and Bob computes $e = \Hash(Y \| \mathrm{Alice})$, then

$$K_{\text{Alice}} = (Y B^{e})^{x + da}, \qquad K_{\text{Bob}} = (X A^{d})^{y + eb}.$$

Both sides obtain $K = g^{(x+da)(y+eb)}$. The session key is $k = \Hash(K)$. No signatures are exchanged. Each party performs one full exponentiation and one half-length exponentiation. The slides also give a signature reading: $(Y B^{e})^{x+da}$ acts as a signature by Alice on $X \| \mathrm{Bob}$. The matching term acts as Bob's signature on $Y \| \mathrm{Alice}$.

On the checklist, agreement holds by the algebra of the previous display, and authentication is implicit in the key computation itself, with the hashes $d$ and $e$ binding the peer name into it.

A key derivation function turns an imperfect source of randomness into one or more random keys. The Diffie-Hellman value $g^{xy}$ is the typical source. Although it is secret, it is not uniform over bit strings, so it must not be used directly as a key. A naive treatment applies a hash once, as in $k = \Hash(g^{xy})$, and derives further keys by hashing again with context strings. The slides point out the flaw: no concrete hash is a random oracle, and Merkle-Damgård hashes admit length extension, so from $\Hash(g^{xy} \| A)$ one can compute $\Hash(g^{xy} \| B)$ whenever $A$ is a prefix of $B$.

Common mistake. The Diffie-Hellman shared secret is used directly as the session key. TLS 1.3 instead runs it through the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), producing separate labeled keys for encryption, integrity and each direction of traffic.

HKDF separates the two jobs. Extract concentrates the dispersed entropy of the source into one fixed-length pseudorandom key, taking the source $K$ and a salt $s$. Expand takes that key, a context string called info and an output length, and derives as many context-bound keys as needed. The extract step is a randomness extractor; the expand step is a Pseudorandom Function (PRF). The salt is not secret and can be reused across exchanges.

$$PRK = \mathrm{HMAC}(salt, IKM),$$ $$T(i) = \mathrm{HMAC}(PRK, T(i-1) \mid info \mid i), \qquad T(0) = \epsilon,$$ $$OKM = \text{first } L \text{ bytes of } T(1) \mid T(2) \mid \cdots$$

The practical instantiation uses A Hash-Based Message Authentication Code (HMAC) for both steps. HKDF is standardized in RFC 5869 and appears in TLS 1.3 and WhatsApp.

The lab below reproduces RFC 5869 case 1, which doubles as a worked DH-to-traffic run. The Diffie-Hellman shared secret plays the role of Input Keying Material (IKM), here as 22 bytes of 0x0b, the salt is 000102...0c, and extract gives

PRK = 077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5

Two expand calls with different info labels then derive two distinct traffic keys:

Both keys come from the same PRK. Each is bound to its own label. Expanding the same PRK under a different info string gives an unrelated output.

Worked number. TLS 1.3 sizes these outputs. From one traffic secret, the label key yields a 16-byte key for the Advanced Encryption Standard in Galois/Counter Mode; the label iv yields a 12-byte base initialization vector, XORed with the 64-bit record sequence number to form each per-record nonce.

HKDF is the wrong tool for passwords. It has no iteration cost and cannot slow an offline dictionary attack; the iterated password constructions of section 13 exist for that job.

The applications on slide 44 show why both roles matter. IPsec uses $k = \mathrm{HKDF}(\text{nonces}, g^{xy})$ with the protocol nonces as salt; if the nonces are public the analysis needs HKDF as an extractor, and if they are secret, as in SKEME, as a PRF. TLS 1.3 resumption uses $k = \mathrm{HKDF}(k_i, g^{xy})$ and again needs both views depending on whether the resumption key is revealed.

A password is a string of symbols from a finite alphabet, equivalently a bit string. It must be stored securely. Its two standard uses are deriving a cryptographic key and authenticating a user. The attacks on slide 47:

• Guessing, either online trial and error or offline dictionary attack.
• Sniffing from networks or theft from servers.
• Software attacks, phishing and shoulder surfing.

The server can throttle online guessing by limiting failed attempts and slowing the response after each failure, while avoiding a denial of service against the real user. Offline guessing cannot be detected once the verifier has leaked. The attacker chooses the resources. The only defense the user controls is the entropy of $\pi$.

For 7-bit ASCII there are 95 printable characters, so uniform passwords carry $\log_2 95 = 6.57$ bits per character, and 128 bits of security requires roughly 20 characters. Restricting to upper and lower case letters plus digits gives $\log_2 62 = 5.95$ bits per character, requiring 22 characters. Passphrases are measured by the entropy rate of the language; the slides give Italian at about 3.15 bits per character for single symbols, 2.22 for pairs and 1.87 in the limit, which means about 69 characters of Italian text for 128 bits.

Those rates hold for passwords drawn uniformly from the alphabet, as a generator would draw them. Human-chosen passwords carry less entropy than the alphabet size suggests, because users pick from a small predictable subset, so their strength is estimated from leaked-password studies; alphabet size alone does not measure it.

Users choose poorly. The Purdue study on slide 53 found that 42% of passwords in the sample had length 8, and among 69 million Yahoo passwords, 1.1% of users picked the same password. Computer-generated passwords are hard to remember; periodic server guessing checks are expensive and annoying; the practical middle ground is checking passwords as entered against simple acceptability guidance.

A server that checks passwords against a dictionary $\mathcal{D}$ faces a tradeoff between accuracy and the time and memory needed to store and query $\mathcal{D}$. A Bloom filter compresses the dictionary into a bit table. Take $k$ hash functions $\Hash_i$ with values in $[0, N-1]$ and set $N = 2^m$. Create a table $T$ of $N$ bits. For every word $w \in \mathcal{D}$, compute $y_i = \Hash_i(w)$ and set $T[y_i] = 1$. To test a proposed password $\pi$, reject it if $T[\Hash_i(\pi)] = 1$ for every $i \in [k]$.

The filter has false positives and no false negatives. If $\pi \in \mathcal{D}$, all $k$ of its bits were set at insertion, so it is always rejected. If $\pi \notin \mathcal{D}$, it may still be rejected, because all $k$ positions may have been set by other words. With $D = |\mathcal{D}|$, the probability a given bit is still zero is

$$q = \left(1 - \frac{1}{N}\right)^{kD} \approx e^{-kD/N},$$

and the false positive rate is

$$p = (1 - q)^k \approx \left(1 - e^{-kD/N}\right)^k.$$

For a fixed target false positive rate, the optimal parameters are $k \approx -\log_2 p$ and $N \approx -1.44 \, D \log_2 p$. The filter never stores the dictionary itself, which also makes it attractive when the table leaks: a leaked Bloom filter reveals membership only probabilistically.

Password Storage

A server never stores $\pi$ itself. It stores a verifier $y = f(\pi, z)$ with a public salt $z$ and a deliberately slow public $f$. The server checks a guess $\pi'$ by testing $y = f(\pi', z)$. The salt separates users, so one rainbow table (a precomputed table of password hashes) does not attack every account at once. The cost of $f$ sets the price of each offline guess once the verifier leaks. The adversary is assumed to hold the salt and $f$.

Password-Based Encryption

Password-based encryption turns a low-entropy password into a key for encrypting a message. The PKCS #5 (Public-Key Cryptography Standard number 5) construction on slide 57 chooses an 8-byte salt, iterates the hash $c$ times with $K = \Hash^{c}(\pi \| \mathrm{salt})$, sets $C = K \oplus M$ and outputs $(\mathrm{salt}, C)$, with $c = 10000$ as the example. The hash chain slows offline attacks by the factor $c$.

The remaining leak is structure. If step 2 of decryption produces recognizable text only for the right password, the attacker knows immediately which guess worked. Honey encryption addresses this by arranging that every plausible password decrypts to a plausible-looking message, so the adversary cannot distinguish the real plaintext from decoys.

PAKE

Authenticated key exchange so far required a public-key infrastructure. Password-authenticated key exchange replaces the infrastructure with a shared password. Its specific guarantee is that an adversary who records a full transcript cannot test password guesses offline, since verifying a guess would require a fresh interaction with a live party. Encrypted Key Exchange is the example on slide 60: Alice sends $C_A = \Enc(\pi_{AB}, g^x)$ and Bob sends $C_B = \Enc(\pi_{AB}, g^y)$, each decrypts with the shared password and computes $k = \Dec(\pi_{AB}, C)^{x}$ or the matching value. The instantiation uses an ideal cipher for $\Enc$ and hashes the transcript with a random oracle.

Standardization took decades from 1982 onward; today PAKE appears in iCloud and in Radio-Frequency Identification (RFID) authentication. The TLS 1.3 pre-shared key mode of section 14 is a PAKE in general only when the PSK itself comes from a PAKE exchange. On its own it resumes from a high-entropy PSK, and if a low-entropy password is used as the PSK, an attacker who recorded the handshake can derive the Finished key for each guess and test it offline against the transcript.

Transport Layer Security applies the chapter's key-exchange mechanisms to a secure channel. The handshake yields keys for confidentiality and authenticity. A record layer secures traffic under those keys, with authentication applied usually on the server side. The client-server scenario on slide 62 is the everyday case: the browser types a domain, TLS is negotiated, the URL switches to https and the user authenticates over the resulting secure link.

Common mistake. TLS encrypts web traffic with the server's public key. Public-key operations happen only during the handshake, for signatures and key agreement. Fast symmetric ciphers such as the Advanced Encryption Standard encrypt the bulk data under keys derived fresh for each session.

SSL (Secure Sockets Layer, the predecessor of TLS) started at Netscape around 1995 and became TLS in 1999. SSL 1.0 was never released, SSL 2.0 shipped in February 1995 with security flaws, SSL 3.0 followed in 1996, and TLS 1.3 arrived in August 2018 as a complete revision. The revision reads best as a table of legacy flaws and the TLS 1.3 response to each.

The slides pair each attack with its proposed and deployed fixes. Backward compatibility kept flawed primitives available through TLS 1.2. TLS 1.3 removed those primitives.

Common mistake. TLS 1.3 removed RSA. It removed RSA key transport, where the client encrypted a secret to the server's public key. RSA certificates remain common: servers still prove identity with RSA-PSS signatures while keys are agreed through ephemeral Diffie-Hellman.

TLS 1.3 with (EC)DHE ((elliptic-curve) Diffie-Hellman ephemeral key exchange) runs the handshake in seven flights. The animation below walks them. The table marks the protection on each one.

Scored against the checklist, (EC)DHE gives secrecy, and forward secrecy as well because the static key material in the run is the signing key, which cannot recover $g^{xy}$ after the ephemerals are erased. The signature $\sigma$ authenticates the server. The two Finished tags give key confirmation in both directions. The transcript inside every Key Derivation Function (KDF) call keeps both sides agreeing on one session.

Common mistake. Whoever obtains the server's certificate can decrypt its traffic. A certificate is a public document that binds a domain name to a public key; decryption needs the matching private key. With ephemeral Diffie-Hellman, even a stolen private key cannot unlock recorded past sessions.

The pre-shared key variant resumes from a shared key, either external or from session resumption (see the PAKE note in section 13). The ClientHello carries early data and PSK modes. The ServerHello selects the PSK. Zero round-trip time pushes this further: the client sends application data immediately, using a semi-static server key that is available only for short periods. The slides credit Google with inventing 0-RTT to reduce latency. In QUIC the client uses an ephemeral key together with the server's semi-static key to derive an early key and encrypt data under it. The server later supplies an ephemeral share for a forward-secure key. The price is replay: the same early ciphertext can be sent again. The only defense shown on slide 74 is for the server to store previously received values.

• Wikipedia: Diffie-Hellman key exchange. The color-mixing analogy, a worked numeric example, a secrecy chart and the man-in-the-middle and Logjam attacks.
• RFC 5869 (HKDF). A readable primary source for extract-then-expand, with the test vectors the HKDF lab on this page reproduces.
• The Joy of Cryptography (Rosulek). Free textbook that treats passive-secure Diffie-Hellman, authenticated key exchange and post-quantum key exchange as three separate definitions.
• A Graduate Course in Applied Cryptography (Boneh and Shoup). Chapters on authenticated key exchange and on lattice-based post-quantum cryptography.
• Practical Cryptography for Developers (Nakov). DHKE, ECDH and KDFs (PBKDF2, Scrypt, Argon2 and HKDF) with code, plus a quantum-safe chapter.
• NIST Post-Quantum Cryptography. Status of FIPS 203 (ML-KEM) and the migration timeline.
• Open Quantum Liboqs (Safe). Run an ML-KEM handshake in Python or through OQS-enabled OpenSSL.

Further reading: Katz and Lindell (2015), Introduction to Modern Cryptography.