Authenticated key establishment

How authentication and key establishment are combined in practice, why both parties should contribute to the session key, how signing Diffie-Hellman values delivers forward secrecy, and what a modern crypto API can and cannot protect against.

State the four engineering principles the lecture gives for session key management.
Reproduce the simple and improved hybrid AKE schemes and explain why the improved one holds up better against a single weak key half.
Reproduce signed Diffie-Hellman and explain exactly how it delivers forward secrecy.
Explain what a modern cryptographic API defends against and what it cannot.

15 min read

Intuition

Authentication on its own answers “who is this.” Most real protocols need to answer that and also walk away with a fresh shared key, in the same handshake. Combining the two well is not automatic: whichever party contributes the key can become a single point of failure if the scheme is not built carefully.

Mechanism

Most protocols combine authentication and key establishment one of two ways: encrypting and sending a password (with challenge-response to stop replay), or using a Diffie-Hellman exchange. Four engineering principles apply regardless of which:

Always generate session keys from your actual, master keys.
Use a session key for one session only, then delete it.
Never reuse a session key.
Both parties should be involved in the key’s creation.

Mechanism

The idea behind a simple AKE is to use long-term asymmetric keys to protect short-term symmetric ones. In the simplest hybrid approach, Alice picks a symmetric key $k$ and sends it, encrypted and signed:

$A \to B: \text{Enc}_{k_{e,B}}(k), \text{Sig}_A(k), \text{ then use } k \text{ for further encryption}$

A better scheme has both sides contribute a half:

$A \to B: \text{Enc}_{k_{e,B}}(k_A), \text{Sig}_A(k_A)$ $B \to A: \text{Enc}_{k_{e,A}}(k_B), \text{Sig}_B(k_B)$

Formula

Combined session key from a mutual hybrid exchange

k = f(k_A \Vert k_B)

$k_A$: the key half A contributes
$k_B$: the key half B contributes
$f$: a combining function applied to both halves

Both sides are now involved in key creation. If one party happens to choose a poor half by accident, the scheme as a whole remains secure. Variants of this construction are in use, but are being phased out.

Mechanism

§7.3 applies the same “both parties contribute” idea directly to Diffie-Hellman. Alice and Bob run the exchange exactly as before, with one addition: each signs their own public value with a long-term private key before sending it, e.g. an RSA signing key.

Alice                                    Bob
Choose random a < p                      Choose random b < p
Compute X = g^a mod p                    Compute Y = g^b mod p
Send X, Sig_A(X) to Bob                  Send Y, Sig_B(Y) to Alice
Compute k = Y^a mod p                    Compute k = X^b mod p

The signature protects exactly the gap plain Diffie-Hellman leaves open: an active attacker trying to substitute a different public value now has to forge a signature under a private key it does not hold, which it cannot do.

EXTRACTION DEFECT: Figures 17 (a Diffie-Hellman recap) and 18 (signing Diffie-Hellman values) did not survive extraction. Both messages survive in full as plain text above, in the slides’ own pseudocode form.

Exam detail

This is the second time forward secrecy appears this week; the first page defines it and explains why DH offers it in principle. Here is the mechanism that actually delivers it: using Diffie-Hellman every time a protocol runs, with a genuinely fresh $a, b$ chosen and the old pair deleted every time, produces ephemeral keys. If an attacker later learns the long-term signing keys, every session’s messages, protected under a session key derived from its own ephemeral $(a, b)$ , stay secure. Learning one session’s exponent pair $(a_i, b_i)$ does not expose any other session’s messages, protected under a different pair $(a_j, b_j)$ , $i \neq j$ . The condition that must hold for this to work is exactly the second and third session-key principles above: a fresh pair every time, and the old one actually deleted, not reused or archived.

Mechanism

§7.4 turns to what modern cryptographic APIs do about all of this. There are, per the lecture, too many ways to get a protocol wrong by hand: inadequate key lengths, poor random-value generation, improper padding, insecure block modes, mixing encryption and authentication incorrectly, reusing nonces or IVs with a stream cipher. Modern APIs limit what a developer can choose in the first place, offering only safe defaults: libsodium/NaCl, the AWS Encryption SDK and Google Tink are named examples, and TLS 1.3 removed weak cipher suites entirely, no RSA key exchange, no CBC mode.

What a modern API cannot prevent is a semantic flaw in the protocol itself, the exact category of mistake this page and the previous one have been walking through by hand. That is why standardised, heavily vetted protocols, such as Kerberos, covered next, are used in practice rather than composed fresh from primitives every time.

Aside

The lecture frames modern APIs as closing off implementation mistakes specifically, not design mistakes. A perfectly implemented call into a safe-defaults library still produces an insecure system if the protocol built around those calls has a replay or authentication gap of the kind covered on the previous page.

Recall

Session keys: derive from master keys, use once, delete, never reuse, and have both parties contribute.
The improved hybrid AKE combines a key half from each side so one weak contribution does not break the scheme.
Signing Diffie-Hellman’s $X$ and $Y$ stops an active attacker substituting a public value.
Forward secrecy from signed DH holds as long as each session’s exponents are fresh and deleted, independent of the long-term signing key.
Modern APIs prevent implementation mistakes, not protocol-design flaws; that gap is why standardised protocols like Kerberos exist.

Source

Week 7 Notes PDF