Chapter 28 — Quantum and post-quantum security: implementation I
Lesson map
Lesson 28 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["28.1 Library selection"]
N2["28.2 Integration through providers"]
N3["28.3 Identifiers and encodings"]
N4["28.4 Stateful signatures"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 Library selection"]
N2["28.2 Integration through providers"]
N3["28.3 Identifiers and encodings"]
N4["28.4 Stateful signatures"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]
[Learning outcomes]
|
v
[28.1 Library selection]
|
v
[28.2 Integration through providers]
|
v
[28.3 Identifiers and encodings]
|
v
[28.4 Stateful signatures]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) select vetted libraries and validated modules; (2) integrate ML-KEM and ML-DSA through provider interfaces; (3) handle encodings, identifiers and interoperability; and (4) implement stateful signature management safely. It builds on Chapters 9, 14 and 27.
28.1 Library selection
Use maintained, reviewed implementations with constant-time code, test vectors and, where required, validation under NIST's Cryptographic Module Validation Program (CMVP). Prefer libraries that implement the final FIPS versions, not draft Kyber/Dilithium. Record the library, version and algorithm identifiers in the CBOM.
CMVP validation takes time, so a library may support ML-KEM well before its validated version is available. BPA's policy accepts unvalidated libraries for pilots and requires validated modules for production on regulated systems, with the dates tracked in the plan.
28.2 Integration through providers
Most platforms expose cryptography through providers (OpenSSL providers, Java security providers, PKCS#11 for HSMs). Integrate PQC by adding or upgrading providers and configuring algorithm names through policy. Applications calling generic interfaces (Chapter 9) need no code changes; those calling algorithm-specific functions do.
This is where the Signer refactoring pays off: BPA's e-document service needs only a new provider and a policy entry, while services that still call algorithm-specific functions each need code changes. The CBOM records which pattern each application uses, which turns a vague estimate of effort into a count of work items.
28.3 Identifiers and encodings
Interoperability depends on exact identifiers: TLS codepoints (0x11EC for X25519MLKEM768 in the IANA registry), X.509 object identifiers for ML-DSA and ML-KEM keys, and key encodings (seed versus expanded key). Mismatches cause failures that look like network faults.
A wrong codepoint makes the server ignore the client's share, so the connection falls back or fails, which an engineer may wrongly diagnose as a firewall problem. Interoperability tests therefore compare identifiers and encodings with the registry and the standards before checking anything else.
28.4 Stateful signatures
LMS/XMSS signing must never reuse a one-time key index. Controls: perform signing in an HSM that enforces monotonic state; reserve index ranges per signer; forbid restoring state from backups; monitor remaining signature capacity (SP 800-208 requires hardware-module key generation and signing for these schemes). If these controls are infeasible, prefer stateless SLH-DSA or ML-DSA.
For BPA's crane firmware, a key with 2^15 signatures and a few releases per year never runs out, so capacity monitoring is a formality; the real control is the HSM's refusal to roll state back.
28.5 Worked example
BPA integrates ML-DSA-65 for bills of lading. The signing service uses an HSM via PKCS#11; verifiers in partner systems use a different library. Interoperability testing reveals that one library expected an expanded private-key format — irrelevant to verifiers but blocking key import in a backup HSM. Resolution: standardize on seed-based key storage and test import/export in both HSMs before production.
The issue would have appeared only during a disaster recovery, when the backup HSM was needed, which is the worst time to find it. Testing import and export before production turned a future outage into a configuration decision.
28.6 Common errors and limits
- Mixing draft and final algorithm implementations.
- Software signing for stateful schemes.
- Assuming identifiers match across vendors.
Draft Kyber or Dilithium code will not interoperate with final ML-KEM or ML-DSA, so mixing them causes failures that look random. Software-only signing for LMS or XMSS cannot guarantee that state is never reused, and SP 800-208 requires a hardware module. Vendors' identifiers and encodings must be checked in tests, as the expanded-key problem showed; a test that imports each key into both HSMs catches this early.
Engineering note
Plan key and certificate formats with migration in mind. Store ML-KEM and ML-DSA private keys as seeds where the standard and module allow it, because seeds are compact and expand deterministically, which simplifies backup and HSM migration. Record which encoding each system uses in the CBOM, test export and import between every pair of modules before production, and keep a written procedure for key ceremonies that names the parameter set, encoding, module firmware version and witnesses.
Exercises
- EX055 — Library checklist. Write a selection checklist for a PQC library. Rubric: 3 = final FIPS versions, constant-time, KATs, maintenance, validation.
- EX056 — State plan. Design LMS state management for two signing sites. Rubric: 3 = index partitioning, no rollback, capacity monitoring.
Synthesis
Implement PQC through vetted, validated providers, exact identifiers and encodings, and rigorous state management for stateful signatures.
Continue studying — chapter 28 of 50
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →