◇ OpenCyber Academy
Engineering · Chapter 27 · English

Chapter 27 — Quantum and post-quantum security: control design

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Quantum and post-quantum security: control design

Lesson map

Lesson 27 published. Map, example, EX053.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Combiner controls"]
  N2["27.2 Practical activity — Lab C"]
  N3["27.3 Negotiation controls"]
  N4["27.4 Key-management controls"]
  N5["27.5 Policy controls"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX053"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Combiner controls"]
  N2["27.2 Practical activity — Lab C"]
  N3["27.3 Negotiation controls"]
  N4["27.4 Key-management controls"]
  N5["27.5 Policy controls"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX053"]

[Learning outcomes]
    |
    v
[27.1 Combiner controls]
    |
    v
[27.2 Practical activity — Lab C]
    |
    v
[27.3 Negotiation controls]
    |
    v
[27.4 Key-management controls]
    |
    v
[27.5 Policy controls]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX053]

Learning outcomes

You will (1) design the controls that make hybrid key exchange secure — combiners, transcript binding and negotiation; (2) design key-management controls for new key types; (3) specify policy controls for allowed algorithms; and (4) test a combiner. It builds on Chapters 24–26.

27.1 Combiner controls

A hybrid key exchange must derive the session key from both shared secrets so that compromise of one does not reveal the key. In X25519MLKEM768 the secrets are concatenated (ML-KEM first) and fed into the TLS 1.3 key schedule, which binds them to the handshake transcript (RFC 10024). Custom combiners outside standard protocols should follow SP 800-56C key-derivation methods, which FIPS 203 permits for ML-KEM shared secrets, and bind context (identities, ciphertexts, transcript).

27.2 Practical activity — Lab C

# Lab C (ch 27): a hybrid key combiner. The session key depends on BOTH shared secrets.
import hashlib, hmac
def hkdf_extract(salt, ikm): return hmac.new(salt, ikm, hashlib.sha256).digest()
def combine(ss_pq, ss_trad, context):
    # Concatenate secrets (PQ first, as in X25519MLKEM768), bind the transcript/context, then extract.
    return hkdf_extract(b"\x00" * 32, ss_pq + ss_trad + context).hex()[:16]
pq, trad, ctx = b"P" * 32, b"T" * 32, b"handshake-transcript-hash"
print("baseline              ", combine(pq, trad, ctx))
print("PQ secret changed     ", combine(b"Q" * 32, trad, ctx))
print("traditional changed   ", combine(pq, b"U" * 32, ctx))
print("context changed       ", combine(pq, trad, b"other-transcript"))

Expected output:

baseline               d48e982e8c06ca60
PQ secret changed      d4c36ea2d90b2e9c
traditional changed    8dcefa12ded3d99c
context changed        af06eca8abcd45a9

Changing either secret or the context changes the output: the derived key depends on both components and on what was negotiated.

Note that only the first characters of the hex output are shown for readability; a real derivation would use the full output and a proper HKDF expand step. Try passing an empty context and compare: the result still depends on both secrets but no longer on the transcript, which is exactly the weakness the context binding prevents.

27.3 Negotiation controls

Algorithm negotiation must be authenticated. TLS 1.3 signs the transcript, so an attacker who strips hybrid groups is detected unless they can forge the server's signature. Application logic that retries without hybrid groups after any failure re-opens downgrade; controls: log and alert on fallback, and disable fallback where all peers support hybrids.

BPA's portal logs every handshake that ends without a hybrid group when the client offered one. A rise in such events triggers an alert, since it could mean an attack or a misbehaving middlebox, and both need investigation.

27.4 Key-management controls

New key types need lifecycle controls: generation in approved modules, storage, rotation, backup and destruction. ML-KEM decapsulation keys can be stored as a 64-byte seed per FIPS 203; stateful hash-based signature keys require state protection against rollback; ML-DSA keys need HSM support.

The 64-byte seed form is compact and avoids format mismatches, as the HSM import problem in the next chapter's example shows. Destruction also needs care: a key must be removed from every backup and HSM partition, and the CBOM entry closed with the date.

27.5 Policy controls

An allow-list of algorithms and parameter sets per context — e.g. "edge TLS: X25519MLKEM768, SecP256r1MLKEM768; fallback X25519 until 2027-12-31" — implemented in configuration and verified by telemetry.

The fallback entry has an end date so it cannot stay forever; after that date, X25519 alone is removed for edge TLS. Telemetry confirms what the configuration claims by counting negotiated groups per day. When the count of classical-only connections approaches zero, the team has evidence that the removal will not break partners, and the change can go through without a long debate.

27.6 Worked example

A BPA team proposes XOR-ing the two shared secrets to save a KDF call. Review rejects it: XOR offers no context binding and is fragile in some security proofs; use the protocol's standard combiner or SP 800-56C derivation with both secrets and context.

Saving one KDF call gains nothing measurable: hashing a few dozen bytes costs microseconds, while a weak combiner could undermine the reason for using a hybrid. The review records the decision in the team's design notes so the idea is not proposed again.

27.7 Common errors and limits

XOR and truncation look harmless but drop the context binding and can weaken security proofs, as the worked example explained. Silent fallback hides downgrade, which is why BPA logs any handshake without the hybrid group. Backing up a stateful signing key like an ordinary key invites state rollback and one-time key reuse after a restore; BPA excludes such keys from routine backups and keeps their state in the HSM.

Exercises

Synthesis

Hybrid security depends on controls: standard combiners with context binding, authenticated negotiation without silent fallback, lifecycle management for new key types and dated allow-lists.

Continue studying — chapter 27 of 50

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →