Chapter 9 — Quantum and post-quantum security: tools and methods
Lesson map
Lesson 09 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Client tools"]
N2["9.2 Practical activity — Lab B"]
N3["9.3 Validating tools"]
N4["9.4 A repeatable method"]
N5["9.6 Hands-on activity"]
N6["9.7 Reading sizes"]
N7["9.9 Comparing results over time"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Client tools"]
N2["9.2 Practical activity — Lab B"]
N3["9.3 Validating tools"]
N4["9.4 A repeatable method"]
N5["9.6 Hands-on activity"]
N6["9.7 Reading sizes"]
N7["9.9 Comparing results over time"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX025"]
[Learning outcomes]
|
v
[9.1 Client tools]
|
v
[9.2 Practical activity — Lab B]
|
v
[9.3 Validating tools]
|
v
[9.4 A repeatable method]
|
v
[9.6 Hands-on activity]
|
v
[9.7 Reading sizes]
|
v
[9.9 Comparing results over time]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) use client tools to check negotiation; (2) estimate handshake sizes for certificate choices; (3) validate a tool before trusting it; and (4) follow a repeatable checking method.
9.1 Client tools
openssl s_client (TLS), ssh -v (SSH), and VPN appliance status commands show negotiated algorithms. Use a client with post-quantum support; an old client will always report classical. Record client version with every result.
At HHG, the scanner in the worked example below reported every server as classical because it bundled an old library. Write the client version next to every result so such errors can be found later. Check the client against a known lab server first, so you know it can report hybrid when it is used.
9.2 Practical activity — Lab B
# Lab B (ch 9): bytes of authentication in a TLS handshake for different signature choices.
# Sizes in bytes: (public key, signature). ML-DSA from FIPS 204; SLH-DSA-128s from FIPS 205.
algs = {"ECDSA P-256": (65, 72), "RSA-2048": (270, 256), "ML-DSA-44": (1312, 2420),
"ML-DSA-65": (1952, 3309), "SLH-DSA-SHA2-128s": (32, 7856)}
def chain_bytes(alg, depth=2, scts=2):
pk, sig = algs[alg]
certs = depth * (pk + sig + 400) # leaf + intermediate: key + CA signature + ~400 B fields
return certs + sig + scts * sig # + CertificateVerify + embedded SCT signatures
for a in algs:
print(f"{a:20s} ~{chain_bytes(a):6d} bytes of certificates and signatures")
Expected output:
ECDSA P-256 ~ 1290 bytes of certificates and signatures
RSA-2048 ~ 2620 bytes of certificates and signatures
ML-DSA-44 ~ 15524 bytes of certificates and signatures
ML-DSA-65 ~ 21249 bytes of certificates and signatures
SLH-DSA-SHA2-128s ~ 40144 bytes of certificates and signatures
Post-quantum certificates make handshakes much bigger. Operators need these numbers when a network team asks why a firewall suddenly sees larger messages after a certificate change.
The script estimates the bytes of certificates and signatures in a TLS handshake for five signature choices, using public key and signature sizes from FIPS 204 and FIPS 205. ECDSA P-256 needs about 1.3 KB; ML-DSA-44 about 15.5 KB, and SLH-DSA-SHA2-128s about 40 KB. These figures explain why certificate changes need network testing. Change the depth or the number of SCTs to see how assumptions affect the totals.
9.3 Validating tools
Before using a scanner on real systems, test it against lab servers with known settings: hybrid preferred, hybrid offered but not preferred, classical only. If the tool cannot tell these apart, do not use its results.
Keep the validation results with the tool's version, and repeat validation after every tool upgrade. At HHG, this step revealed the scanner's old OpenSSL before its results could mislead anyone. A tool you cannot validate should not produce findings, however convenient it is. Keep the record.
9.4 A repeatable method
- Confirm scope. 2. Record tool and version. 3. Run the check. 4. Save the output. 5. Compare with the expected result. 6. Record the finding or "as expected". Repeating the same steps makes results comparable over time.
Write the method into a short checklist and follow it every time, even for quick checks. Step 5 is where surprises appear, and each surprise should lead to a finding or a note explaining why the result is expected. Record the scope reference with the saved output. Use the same steps for automated checks.
9.5 Worked example
An HHG operator's scanner reports every server as classical. Testing against the lab shows the scanner bundles an old OpenSSL. After upgrading, it correctly identifies the lab's hybrid server; only then is it used on the staging estate, within scope.
Without the lab test, the scanner would have produced a false report that the whole estate was classical, and effort would have gone into the wrong services. Validation took a short time and saved much more. Record the validation with the scanner's version.
9.6 Hands-on activity
Validate one TLS client tool against three lab server settings and record the results.
Set up three lab servers or three configurations on one server: hybrid preferred, hybrid offered but not preferred, and classical only. Run the tool against each, record its version and output, and say whether it correctly told the three apart. If it did not, note what it reported and whether a newer version fixes it. File these results in the tool's validation record, described earlier in this chapter, and note the date of the run.
9.7 Reading sizes
Lab B's numbers are estimates under stated assumptions: two certificates in the chain, about 400 bytes of other certificate fields, two certificate-transparency signatures. Real chains can be longer or shorter. When you need exact numbers for a firewall rule or a ticket, capture a lab handshake and measure it, then note the configuration it came from.
Keep measured values with the ticket. At HHG, a firewall team asking about the guest portal would need measured values, not the Lab B estimate. Treat estimates as a guide to the order of size.
9.8 Common errors and limits
- Using unvalidated tools.
- Results without client versions.
- Treating size estimates as measurements.
Each error makes results unreliable. An unvalidated tool can misreport the whole estate, as HHG's scanner with an old OpenSSL did. Results without client versions cannot be checked later, since an old client always reports classical. Lab B's size figures rest on stated assumptions, so a firewall rule built on them may be wrong; measure a real lab handshake before using numbers in a ticket. Check your notes for each of these.
9.9 Comparing results over time
Keep each check's saved output in a dated folder so that next month's run can be compared line by line. A simple diff between two runs of the same script quickly shows which services changed negotiation, which is often faster than reading a dashboard when you are investigating a specific complaint.
Keep the folder names consistent so scripts can find the runs. At HHG, comparing dated runs is how the nightly job spotted the two endpoints that switched to classical after a patch.
Exercises
- EX025 — Tool validation. Describe the three lab settings and expected results for validating a scanner. Rubric: 3 = three settings with expected outputs.
- EX026 — Size ratio. From Lab B, roughly how many times larger is ML-DSA-44 authentication than ECDSA P-256? Rubric: 3 = about 12 (15,524/1,290).
- EX027 — Method. List the six steps of a repeatable check. Rubric: 3 = all six in order.
Synthesis
Operators use validated, current client tools, record versions, follow a repeatable method and understand the size effects of post-quantum certificates.
Continue studying — chapter 09 of 18
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →