Key Exchange in TLS

TLSv1.2 & TLSv1.3 with Post-Quantum Cryptography (PQC)

Why PQC changes the key exchange

Threat model (high-level)

• Classical public-key cryptography (e.g., RSA, and ECC schemes used in Diffie–Hellman/ECDHE) could become vulnerable if large-scale quantum computers can run relevant quantum algorithms.
• TLS key exchange establishes the shared secret used to derive:
  • symmetric session keys (encryption keys),
  • integrity keys (MAC/AEAD),
  • and traffic keys for the session.

PQC approach in TLS

Because TLS key exchange produces critical session secrets, PQC deployment commonly uses:

• Hybrid key exchange: combine a classical key agreement (for immediate compatibility/security) with a post-quantum KEM-based key agreement (for quantum resilience).
• A typical design goal: if either component remains secure, the resulting shared secret remains secure (often via “key combining” and KDF usage).

TLS 1.2 Key Exchange: baseline (no PQC)

Common TLS 1.2 key exchange modes

TLS 1.2 can use multiple key exchange patterns:

1. RSA key transport (server encrypts a premaster secret with client’s RSA public key)
2. (EC)DHE / ECDHE key agreement (forward secrecy)
3. Variants using different certificate/key exchange combos

For “key exchange process” with forward secrecy, the relevant one is usually (EC)DHE/ECDHE.

TLS 1.2 with (EC)DHE (typical handshake flow)

Goal: agree on a premaster secret / shared secret, then derive session keys.

1. ClientHello
   • Client proposes cipher suites and supported parameters.
2. ServerHello + Certificate
   • Server selects a cipher suite.
   • Server sends its certificate (identity) and public key info.
3. ServerKeyExchange
   • Server provides key agreement material (e.g., ephemeral Diffie–Hellman public value).
   • This message is typically signed (or otherwise authenticated) to bind the key exchange to the server identity.
4. ClientKeyExchange
   • Client sends its ephemeral key agreement public value (e.g., its ECDHE share).
5. ChangeCipherSpec / Finished
   • Both sides compute the shared secret.
   • Apply TLS 1.2 PRF / key schedule to derive:
     • encryption keys,
     • MAC keys,
     • IVs/nonces,
   • Verify Finished messages to ensure integrity of the handshake.

Security properties

• With (EC)DHE: forward secrecy (compromise of long-term keys later shouldn’t reveal past sessions).
• Integrity/authentication come from:
  • server authentication (certificates),
  • signature/authentication of ephemeral key material.

TLS 1.2 with PQC (conceptual hybrid key exchange)

Where PQC fits in TLS 1.2

TLS 1.2 does not have a standardized “PQC key schedule” inside the core spec the way TLS 1.3 is structured. So PQC integration in TLS 1.2 is typically described as:

• Use a PQC Key Encapsulation Mechanism (KEM) to derive a shared secret.
• Combine it with a classical (EC)DHE shared secret (hybrid).
• Feed the combined secrets into the existing TLS 1.2 key derivation (PRF) or an equivalent KDF/combining step (implementation dependent).

Hybrid handshake flow (high-level)

Assume:

• Classical ephemeral key agreement: produces Z_classical
• PQC KEM: produces Z_pqc
• Combined secret: Z_hybrid = Combine(Z_classical, Z_pqc)

Process mapping into TLS 1.2 messages:

1. ClientHello
   • Client advertises PQC-capable ciphers / extensions.
2. ServerHello + Certificate
   • Same role: server identity.
3. ServerKeyExchange
   • Contains classical ephemeral parameters (for (EC)DHE)
   • Plus PQC KEM-related public/offer material (as defined by the PQC/TLS integration design).
4. ClientKeyExchange
   • Client sends:
     • its classical ephemeral share
     • PQC encapsulation output (or the encapsulated key material, depending on KEM direction)
5. Shared secret computation
   • Both compute:
     • Z_classical from classical ephemeral shares
     • Z_pqc via PQC KEM decapsulation (client) / decapsulation (server) as appropriate
   • Compute Z_hybrid
6. Key derivation
   • Derive traffic keys (TLS 1.2 PRF / KDF stage) from Z_hybrid
7. Finished
   • Verify handshake integrity.

Key point for TLS 1.2 writing

When you explain TLS 1.2 + PQC, emphasize:

• TLS 1.2 key exchange messages (ClientKeyExchange / ServerKeyExchange) are the “hook points.”
• The shared secret derivation becomes hybrid.
• The rest of TLS 1.2 (ChangeCipherSpec/Finished) is conceptually similar, but keys come from the combined secret.

TLS 1.3 Key Exchange: baseline (no PQC)

What is different in TLS 1.3

TLS 1.3 uses a more structured handshake and derives secrets via a standardized key schedule (HKDF-based). It typically uses:

• (EC)DHE for forward secrecy (selected via cipher suite / key_share)
• certificates for authentication (server-side, plus optional client auth)
• a key schedule that produces traffic secrets from handshake secrets

TLS 1.3 handshake flow (key exchange perspective)

1. ClientHello
   • Includes:
     • supported_versions
     • signature algorithms
     • key_share entries (client ephemeral public keys for selected groups)
2. ServerHello
   • Includes:
     • chosen group
     • server’s key_share ephemeral public key
3. EncryptedExtensions / Certificate / CertificateVerify
   • Server authenticates its identity (certificate + signature over handshake transcript)
4. (Client may also authenticate)
   • For mutual TLS, client sends certificate + signature
5. Finished
   • Keys are derived from shared secret computed from ephemeral shares:
     • Z_classical = DH(client_share, server_share)
   • TLS 1.3 HKDF key schedule derives:
     • handshake traffic keys,
     • then application traffic keys after handshake completion.

Security properties

• Strong forward secrecy via ephemeral (EC)DHE.
• Transcript binding via Finished + signature over transcript (CertificateVerify).

TLS 1.3 with PQC (hybrid KEM + DHE concept)

Where PQC maps in TLS 1.3

TLS 1.3 is generally easier to extend with PQC because its handshake already centers around:

• “shared secret” creation,
• then a standardized HKDF key schedule.

In PQC hybrid designs:

• Classical: ECDHE provides Z_classical
• PQC: a KEM provides Z_pqc
• Combine to Z_hybrid (or feed both into a key schedule mechanism), then HKDF derives traffic secrets.

Hybrid handshake flow (high-level)

1. ClientHello
   • Client includes:
     • classical key_share (ECDHE)
     • PQC key encapsulation/offer parameters (depending on how PQC is expressed in TLS extensions)
2. ServerHello
   • Server selects both:
     • classical group
     • PQC KEM parameters/mode
   • Server sends:
     • its classical ephemeral key_share
     • its PQC KEM response (or the extension requires)
3. Compute hybrid secrets
   • Client computes:
     • Z_classical from ECDHE shares
     • Z_pqc by decapsulating PQC KEM material
   • Server computes:
     • Z_classical from ECDHE shares
     • Z_pqc from its KEM decapsulation counterpart
   • Combine:
     • Z_hybrid = Combine(Z_classical, Z_pqc)
4. Key schedule (HKDF)
   • TLS 1.3 derives handshake and application traffic secrets from the hybrid shared material.
5. Authentication + Finished
   • Certificate and CertificateVerify ensure authentication.
   • Finished confirms both sides derived the same keys.

Key point for TLS 1.3 writing

When you explain TLS 1.3 + PQC, emphasize:

• TLS 1.3 already has the “plumbing” of secret derivation via HKDF.
• PQC integration mostly changes:
  • how the shared secret(s) are created,
  • and how those feed into the key schedule.

Comparison summary: TLS 1.2 vs TLS 1.3 + PQC

Practical considerations (what readers should know)

1. Negotiation: client and server must agree on:
   • classical group(s),
   • PQC KEM(s),
   • hybrid combination rules.
2. Message size: PQC keys/ciphertexts can increase:
   • handshake sizes,
   • latency and bandwidth usage.
3. Certificate vs key exchange: PQC key exchange typically focuses on:
   • secrecy of session keys,
   • not necessarily replacing signatures/cert formats (though some PQC deployments do address both).
4. Long-term security: the motivation is “store now, decrypt later” risk reduction.