The post-quantum toolkit
Hybrid key exchange, certificates, and signatures
What a hybrid TLS handshake protects today, the gap between confidentiality and authentication, and why bigger keys and signatures are a real constraint.
8 min read · 7 min 6 sec film
What you'll be able to do
- Explain what hybrid key exchange is, and what X25519MLKEM768 protects today.
- Distinguish an observed key-exchange group from certificate and signature authentication.
- Describe why larger post-quantum keys and signatures are a genuine migration constraint, not a rounding error.
Lesson film
Watch: Hybrid key exchange, certificates, and signatures
The same handshake from lesson one, one line different — and everything that line does not yet cover.
7 min 6 sec · 9 scenes
7 min 6 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
Everything so far has been about what will need to change. This lesson is about what already has.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. What is already running
2. Two mechanisms, one secret
3. The same handshake, again
4. Already the default
5. What it does not cover
6. They fail differently
7. Size is a real constraint
8. Where size bites
9. Takeaway
The written lesson
Hybrid key exchange combines a classical mechanism, such as X25519, with a post-quantum KEM such as ML-KEM and derives a shared secret from both. Against an adversary who records an authenticated handshake and its encrypted traffic, correct composition is designed to preserve confidentiality if at least one component remains sound. Authentication, endpoint security, implementation, and actual negotiation still matter.
Where correctly negotiated and composed, hybrid exchange can strengthen handshake confidentiality against passive harvest-now-decrypt-later. It does not by itself establish authentication: inspect the certificate signature scheme, chain, negotiation integrity, and endpoint behavior separately. A classical certificate signature such as RSA or ECDSA remains a distinct migration concern where present.
| What | What a negotiated hybrid group establishes | What needs separate evidence |
|---|---|---|
| Handshake confidentiality (the session key) | A hybrid shared-secret input for that TLS hop | Correct composition, peer negotiation, other hops, and endpoint security |
| Server authentication (the certificate) | Nothing about the signature or certificate chain by itself | Observed signature scheme, certificate chain, and trust-anchor lifecycle |
Post-quantum keys, ciphertexts, and especially signatures are measurably larger than their classical equivalents. A lattice-based signature such as ML-DSA is several times the size of a comparable ECDSA signature, and a hash-based SLH-DSA signature is larger still. That is not a rounding error: certificate chains, protocol message-size limits, and embedded systems with fixed buffer sizes all have real ceilings, and a migration plan has to check them rather than assume a drop-in swap.
RFC 10024 standardizes X25519MLKEM768 as a TLS 1.3 supported group. A captured TLS trace can show which group was negotiated; it cannot prove the same choice on every client, origin hop, or later connection. Certificate signature, chain validation, and symmetric record protection are separate observations.
| Published parameter | What its size means | Size |
|---|---|---|
| ML-KEM-768 encapsulation key | Public key sent to encapsulate | 1,184 bytes |
| ML-KEM-768 ciphertext | Sent so the recipient can decapsulate | 1,088 bytes |
| ML-DSA-65 signature | One signature, before certificate overhead | 3,309 bytes |
Work it through
F01: interpret the whole protection path
This synthetic evidence describes one client visit and a separate origin connection. Decide exactly what is supported, what remains unknown, and what to pilot first.
About 20 min of unscored practice
Evidence supplied for this exercise
| Evidence | Observed value | Limit |
|---|---|---|
| Client to CDN | TLS 1.3 negotiated group X25519MLKEM768; AES-256-GCM records | One sampled handshake; other clients may differ |
| CDN certificate | Leaf and chain signed with ECDSA | Authentication remains classical on this hop |
| CDN to origin | Configuration says TLS 1.3; negotiated group not recorded | TLS version alone does not identify group |
| Backup | AES-256 data key; wrapping-key origin undocumented | Cannot infer quantum exposure from AES alone |
Your task
- Label confidentiality, authentication, and record encryption for each evidenced hop.
- List two conclusions the trace supports and two it does not support.
- Propose a verification or pilot sequence with a rollback criterion.
Type here or copy the template. Your response stays in this page and is not submitted or scored.
Reveal model response and self-check rubric
A different answer can be sound when it states its assumptions and follows the evidence.
The sampled client-to-CDN handshake used hybrid key exchange and AES-256-GCM records. Its certificate chain is ECDSA, so this evidence does not establish post-quantum authentication. Neither the origin connection nor the backup wrapping path is determined. First sample origin handshakes for each relevant client class and trace the backup key hierarchy. Pilot a supported hybrid origin group, verify negotiation and interoperability, and roll back if supported clients cannot connect or the measured coverage drops below the agreed baseline.
An alternative first pilot can be justified if the backup is higher impact and its key path is quickly verifiable. It must not classify the backup as safe or broken solely from the AES label.
Self-check
For each point: 0 = absent or incorrect, 1 = partly supported, 2 = well supported.
- Separate direct observations from inferred or unknown states.
- Distinguish key exchange, certificate authentication, and record encryption.
- Identify the unmeasured hops and key path.
- Give a feasible next observation, pilot, and rollback trigger.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- RFC 10024: PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3IETF · Standards-track RFC, August 2026 · checked 2026-09-26
- FIPS 203: Module-Lattice-Based Key-Encapsulation MechanismNIST · Final standard · Sections 3.1 and 8; Table 3 (parameter sizes) · checked 2026-09-26
- FIPS 204: Module-Lattice-Based Digital Signature StandardNIST · Final standard · Table 2 (key and signature sizes) · checked 2026-09-26
- FIPS 205: Stateless Hash-Based Digital Signature StandardNIST · Final standard · checked 2026-09-26
Marking a lesson complete only updates this browser.