Authenticated key establishment

Session keys need fresh contributions and a limited lifetime

Protocols often need to authenticate a party and establish a fresh shared key in the same handshake. If only one party contributes the key, that choice can become a single point of failure.

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.

Both parties contributing protects against one weak key half

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.

Signing fresh Diffie-Hellman values adds authentication and forward secrecy

§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.

Exam detail

Forward secrecy requires a fresh $a, b$ for every run and deletion of the old pair. These are 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.

Safe cryptographic APIs prevent implementation mistakes, not protocol flaws

§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.

Optional 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.