Chapter 16 — Quantum and post-quantum security: methods II
Lesson map
Lesson 16 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Signature options"]
N2["16.2 Practical activity — Lab B"]
N3["16.3 Internal PKI changes"]
N4["16.4 Code and firmware signing"]
N5["16.7 HSMs and key formats"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Signature options"]
N2["16.2 Practical activity — Lab B"]
N3["16.3 Internal PKI changes"]
N4["16.4 Code and firmware signing"]
N5["16.7 HSMs and key formats"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[Learning outcomes]
|
v
[16.1 Signature options]
|
v
[16.2 Practical activity — Lab B]
|
v
[16.3 Internal PKI changes]
|
v
[16.4 Code and firmware signing]
|
v
[16.7 HSMs and key formats]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) explain ML-DSA, SLH-DSA, LMS and XMSS from an implementer's view; (2) estimate certificate-chain sizes; (3) plan internal PKI changes; and (4) choose signatures for code and firmware signing.
16.1 Signature options
ML-DSA (FIPS 204): fast, moderate sizes (44/65/87: public keys 1,312/1,952/2,592 bytes; signatures 2,420/3,309/4,627 bytes). SLH-DSA (FIPS 205): hash-only assumptions, 32–64-byte public keys, 7,856–49,856-byte signatures, slower signing. LMS/XMSS (SP 800-208): compact, stateful, to be used in hardware modules that manage state.
For KLS the choice follows the use: ML-DSA for the internal CA, mesh mTLS and release signing; SLH-DSA or LMS only where signing is rare and verifiers are simple, such as scanner firmware. Statefulness rules LMS out for any signer that is not a hardware module with managed counters.
16.2 Practical activity — Lab B
# Lab B (ch 16): 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
The model counts two certificates (leaf and intermediate), each carrying a public key, a CA signature and about 400 bytes of other fields, plus the CertificateVerify signature and two embedded SCT signatures. It is approximate on purpose, but the ordering is robust: ECDSA P-256 needs about 1.3 kB, RSA-2048 about 2.6 kB, ML-DSA-44 about 15.5 kB, ML-DSA-65 about 21.2 kB and SLH-DSA-SHA2-128s about 40.1 kB. The ML-DSA-44 increase of 14,234 bytes over ECDSA is what KLS weighs for the mesh. Note that SCTs belong to public certificates; an internal chain without SCTs is smaller, so rerun the function with scts=0 for mesh leaves.
16.3 Internal PKI changes
For the internal CA: confirm HSM support for ML-DSA key generation and signing; create an ML-DSA root and intermediate in a lab; issue test leaves; test every relying party (ingress, mesh sidecars, Java services, monitoring agents) for chain validation; then distribute the root to trust stores in production before issuing production leaves. Keep the classical hierarchy in parallel.
KLS's relying-party list for the pilot had eleven entries; the monitoring agents and two Java services failed chain validation in the first lab run and needed library upgrades before the root could be distributed. That finding is why the parallel classical hierarchy stays in place until every relying party passes.
16.4 Code and firmware signing
For release artefacts verified for years, ML-DSA is the practical choice once package tooling supports it; consider dual signatures (classical plus ML-DSA) during transition so old verifiers still work. For firmware signed rarely, LMS in an HSM or SLH-DSA is attractive because verification is simple and assumptions conservative.
KLS's release artefacts are verified by customers' deployment tools for years, so dual signatures are the practical path: the existing RSA-3072 signature for current verifiers and an ML-DSA signature for upgraded ones. The scanner vendor is asked whether its bootloader can verify LMS or SLH-DSA in the next hardware generation.
16.5 Worked example
KLS's mesh uses 90-day ECDSA leaves. Lab B suggests ML-DSA-44 chains add ~14 kB per handshake. Inside a data centre that cost is acceptable; on scanner links over cellular it may not be. Plan: ML-DSA-44 for mesh mTLS after lab validation; scanners stay classical until vendor refresh, documented as residual risk.
The plan also records why the scanners differ: a 14 kB chain on every reconnect over a lossy cellular link adds segments and retransmissions, and the vendor's TLS library cannot verify ML-DSA anyway. The mesh decision is reversible because leaves are 90-day and the classical hierarchy remains, so a failed canary means reissuing ECDSA leaves, not rebuilding the PKI.
16.6 Common errors and limits
- Using LMS/XMSS in software without protected state.
- Issuing PQ leaves before trust stores accept the root.
- Ignoring HSM firmware support.
Each mistake has a specific cost. LMS state kept in a software file can be restored from a backup and an index reused, which breaks the scheme; that is why SP 800-208 expects hardware state management. Issuing PQ leaves early fails validation everywhere the root is absent, as KLS's lab showed with the Java services. And an HSM whose firmware lacks ML-DSA turns a planned ceremony into a vendor upgrade project; KLS checks firmware support before booking ceremony dates.
16.7 HSMs and key formats
HSM vendors add post-quantum algorithms in firmware releases, and key formats differ between products. Before committing to an ML-DSA root, test in the lab: key generation inside the HSM, signing a certificate, exporting the public key in the encoding your CA software expects, backing up and restoring the key under the vendor's procedure, and failover between cluster members. Record firmware versions and procedures in the key-ceremony document. Discovering a format mismatch during a production ceremony costs far more than a day of lab testing.
Exercises
- EX031 — Chain size. From Lab B, how many more bytes does ML-DSA-44 use than ECDSA P-256? Rubric: 3 = 14,234 bytes.
- EX032 — Signature choice. Choose a signature for KLS's container image signing and justify. Rubric: 3 = ML-DSA (possibly dual) with verifier support reasoning.
Synthesis
Signature migration trades size, speed, statefulness and assumptions. Implementers start with internal PKI and long-lived signing after confirming HSM and relying-party support.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →