Chapter 18 — Quantum and post-quantum security: controls | Technologist Quantum and post-quantum security

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

Lesson map

Lesson 18 published. Map, example, EX035.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Key-exchange controls"]
  N2["18.2 Data and key controls"]
  N3["18.3 Central profiles"]
  N4["18.4 Residual risk"]
  N5["18.6 Practical activity"]
  N6["18.8 Rolling out controls"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX035"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Key-exchange controls"]
  N2["18.2 Data and key controls"]
  N3["18.3 Central profiles"]
  N4["18.4 Residual risk"]
  N5["18.6 Practical activity"]
  N6["18.8 Rolling out controls"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX035"]

[Learning outcomes]
    |
    v
[18.1 Key-exchange controls]
    |
    v
[18.2 Data and key controls]
    |
    v
[18.3 Central profiles]
    |
    v
[18.4 Residual risk]
    |
    v
[18.6 Practical activity]
    |
    v
[18.8 Rolling out controls]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX035]

Learning outcomes

You will (1) implement hybrid key exchange controls for TLS, SSH and IPsec; (2) implement data-minimization and key-management controls; (3) apply central crypto profiles; and (4) document residual risk per service.

18.1 Key-exchange controls

TLS: enable X25519MLKEM768 and prefer it on internet-facing and tier-1 listeners. SSH: place mlkem768x25519-sha256 first in server KexAlgorithms where OpenSSH versions support it. IPsec: configure an additional ML-KEM key exchange per RFC 9370 where appliances support it, or RFC 8784 PSKs as an interim measure on fixed site-to-site links.

For KLS this means the gateway, portal, origin load balancer and ingress get the kls-modern TLS profile; the SFTP hosts get the hybrid-first KexAlgorithms line; and the office VPN, whose appliances lack RFC 9370 support, uses RFC 8784 PSKs with quarterly rotation until the appliance refresh.

18.2 Data and key controls

Send less long-lived data across untrusted links; encrypt sensitive fields at the application layer with keys that never cross the network under classical key exchange; shorten retention where contracts permit. Keep keys in HSM or KMS; record their algorithms in the inventory.

For KLS the strongest data control is application-layer encryption of customs document fields with keys from the KMS, so recorded transport sessions expose ciphertext even where key exchange is still classical. Shorter retention of scanner telemetry, from one year to 90 days, needed only a contract check.

18.3 Central profiles

Define named crypto profiles (for example kls-modern: TLS 1.3 only, groups X25519MLKEM768:X25519, ECDSA certificates) and apply them by reference in ingress, load balancers and service templates. Changing the profile changes all users after testing.

KLS stores profiles in one repository with version numbers. Ingress manifests reference kls-modern@3 rather than group strings, and the CI gate renders each manifest and compares the result with the profile. A new version is rolled out by canary, and the previous version stays available for rollback without touching application code.

18.4 Residual risk

For each service record what remains classical (usually authentication), what is unknown, and what depends on third parties, with owner and review date.

KLS keeps residual notes in the inventory, one per tier-1 service. A typical entry: "API gateway: key exchange hybrid; certificate ECDSA P-256 (forge-later, awaiting public CA and browser ML-DSA support); payment-provider calls: hybrid support unknown (vendor ticket open); owner Platform Team; review 1 March." The review date matters most, because residual notes without dates become permanent acceptance by default.

The gateway entry, for instance, carries a separate line "unknown: whether the payment provider's endpoint supports hybrid groups", owned by the Platform Team until the vendor ticket is answered; folding it into the classical line would have recorded a guess as an accepted risk.

18.5 Worked example

Partner SFTP: OpenSSH upgraded; KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256; partners using older clients still negotiate curve25519 and are notified; sessions using the hybrid are monitored. Residual: Ed25519 host key (forge-later), partners on old clients (HNDL until they upgrade), owner Platform Team, review quarterly.

The ordered list gives three tiers of client support: current OpenSSH negotiates the ML-KEM hybrid, somewhat older versions the sntrup761 hybrid, and old clients fall back to curve25519. Monitoring by algorithm shows which partners sit in each tier and drives the notices.

18.6 Practical activity

Write a kls-modern profile for one product you use and apply it in a lab.

For NGINX, the profile is a short include file with ssl_protocols TLSv1.3;, ssl_ecdh_curve X25519MLKEM768:X25519; and the certificate directives, referenced from each server block; for OpenSSH, it is a drop-in file under sshd_config.d with the KexAlgorithms line. Apply it in the lab, verify negotiation with two clients, then deliberately remove the hybrid group and confirm your check reports classical. Record the profile version and the file's hash in the lab record.

18.7 Common errors and limits

Per-service hand configuration.
Controls without residual-risk notes.
PSKs without rotation.

KLS's audit found all three before the profile repository existed: eleven hand-edited ingress configurations with four different group lists; a VPN using PSKs with no residual note at all; and PSKs installed at the appliance commissioning, never rotated since. The fixes were a central profile, a residual note per tier-1 service, and a rotation calendar with an owner. Controls reduce exposure only where they are applied consistently and their gaps are written down.

18.8 Rolling out controls

Apply each control through the normal change process: test in staging with the client matrix, enable for a canary share of traffic, watch dashboards, then promote. Keep the previous profile version available for a fast, targeted rollback. Announce changes that affect partners — SFTP and API clients — with enough notice and a test endpoint, so partners can check their clients before production changes. A control that breaks a partner's nightly upload will be reverted under pressure, often without anyone recording why.

KLS's SFTP change followed this path: a partner notice with a test endpoint three months ahead, a canary on one of two SFTP hosts, and promotion after a week without new no_shared_group errors in the logs.

Exercises

EX035 — SSH control. Write the SSH server KEX line for a hybrid-first configuration with a classical fallback. Rubric: 3 = hybrid first, valid names, fallback present.
EX036 — Residual note. Write a residual-risk note for the office VPN using RFC 8784 PSKs. Rubric: 3 = remaining risks, owner, review, exit condition.

Synthesis

Key-exchange, data and key controls applied through central profiles reduce quantum exposure; residual risk is recorded per service.

Continue studying — chapter 18 of 30

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →