Chapter 15 — Quantum and post-quantum security: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX043.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Every hop counts"]
N2["15.2 Controllers"]
N3["15.3 Requests"]
N4["15.4 Practical activity — Lab A"]
N5["15.6 Hands-on activity"]
N6["15.7 Tracking dependencies"]
N7["15.9 Routing around a dependency"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX043"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Every hop counts"]
N2["15.2 Controllers"]
N3["15.3 Requests"]
N4["15.4 Practical activity — Lab A"]
N5["15.6 Hands-on activity"]
N6["15.7 Tracking dependencies"]
N7["15.9 Routing around a dependency"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]
[Learning outcomes]
|
v
[15.1 Every hop counts]
|
v
[15.2 Controllers]
|
v
[15.3 Requests]
|
v
[15.4 Practical activity — Lab A]
|
v
[15.6 Hands-on activity]
|
v
[15.7 Tracking dependencies]
|
v
[15.9 Routing around a dependency]
|
v
[Worked example] --> [Exercise EX043]
Learning outcomes
You will (1) trace a flow across all hops; (2) identify who controls each hop; (3) prepare vendor and partner requests; and (4) understand agility through policy rather than code.
15.1 Every hop counts
A booking from a travel agency reaches HHG through the agency's system, the file-exchange server, an internal processor and the reservations database. Each hop negotiates separately. A hybrid connection at one hop says nothing about the next.
For the agency booking flow, check each hop and record its evidence separately. A dashboard figure for the SFTP server does not cover the internal processor or the database connection. Draw the flow with every hop and mark which ones have evidence of hybrid key exchange and which do not.
15.2 Controllers
Write who controls each hop: HHG operations, a vendor, a cloud provider or a partner. HHG can change its own servers; for the rest it can only ask, require in contracts or route around.
For the channel booking flow, the agencies' clients are partner-controlled, the SFTP server and internal processor belong to HHG, and the reservations database is a managed service. Record each controller with a contact and the route HHG can use to influence it. Keep the list current.
15.3 Requests
A good vendor or partner request names the product and version, asks which post-quantum algorithms and protocols are supported, by which version and date, and asks for a test system. Record answers as vendor evidence until verified.
At HHG, the request to the managed database provider would name the service tier, ask about hybrid key exchange on client connections, and request dates and a test endpoint. Keep a copy of each request and set a follow-up date. Grade answers as vendor evidence.
15.4 Practical activity — Lab A
# Lab A (ch 15): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
"hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
if alg not in POLICY["accept"]: return False # algorithm identifier is authenticated by policy
return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"guest folio 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256" # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"] # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))
Expected output:
old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False
Systems that read algorithm choices from policy can change them without code changes. When you ask vendors about readiness, ask whether algorithms are configurable.
The script stores the algorithm name with each tag and chooses algorithms from a policy rather than from code. Changing the policy moves new tags to SHA3-256 while old tags still verify, and removing the old algorithm from the accepted list retires it cleanly. That is what crypto-agility means in practice. Ask whether a vendor's product works this way before you buy it.
15.5 Worked example
The channel SFTP flow: travel agency client (partner) → HHG SFTP server (HHG) → internal processor (HHG) → reservations DB (managed service provider). After upgrading OpenSSH and enabling hybrid KEX, 5 of 9 agencies negotiate hybrid; four use old clients. HHG sends them a notice with a test endpoint and a twelve-month window.
The flow shows that one upgrade at HHG protects only part of the path. Five agencies benefit now; the other four depend on their own client upgrades. Each hop and its evidence goes into the dependency list.
15.6 Hands-on activity
Trace one HHG flow with all hops and controllers and draft one vendor request.
Pick a flow such as the agency bookings or guest portal logins. List each hop with its protocol, controller and evidence. Then draft a vendor request for one hop HHG does not control: name the product and version, ask which post-quantum algorithms and protocols are supported, from which version and date, and ask for a test system. Record the expected answer type. Check it with a peer.
15.7 Tracking dependencies
Keep a simple dependency list: hop, controller, request sent, answer, evidence grade, next follow-up date. Review it monthly. Dependencies that never get answered are risks to raise with your manager, not tasks to forget.
When an answer arrives, update the evidence grade and the CBOM together. At HHG the list includes the four agencies on old SFTP clients, with their notice dates and the twelve-month window, and the managed database provider's request. Remove an entry only when the hop is verified or the dependency is formally accepted.
15.8 Common errors and limits
- Judging a flow by one hop.
- Treating vendor claims as facts.
- No follow-up on unanswered requests.
Each error leaves risk unseen. Judging the agency flow by the SFTP hop alone would miss the managed database. A vendor's claim is not evidence until it is tested. A request with no follow-up date tends to be forgotten, leaving the hop unprotected without anyone deciding it. Check your dependency list for all three each month. Fix any you find. Note any request that has waited longer than a month.
15.9 Routing around a dependency
When a controller cannot or will not change soon, sometimes HHG can protect the data another way: move the sensitive part of a transfer to a channel HHG controls, reduce what is sent, or terminate a hybrid connection at an HHG gateway close to the partner. Each workaround needs approval and an entry in the exception register, because it changes the service design.
Record each workaround's end date. At HHG, the Summit interim listener was this kind of change and was recorded as an exception until the firewall was fixed.
Exercises
- EX043 — Hop list. List the hops and controllers for the guest portal flow. Rubric: 3 = client, CDN/LB, app, DB with controllers.
- EX044 — Vendor request. Write a four-question vendor request for the door-lock hub. Rubric: 3 = algorithms, protocols, version/date, test system.
- EX045 — Agility question. Why ask vendors whether algorithms are configurable? Rubric: 3 = future change without replacement.
Synthesis
Integration means every hop and its controller; operators send precise requests, track answers and favour configurable products.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →