Quantum-Safe Cryptography Systems
Plan post-quantum migration with cryptographic inventory, NIST ML-KEM and ML-DSA profiles, protocol envelopes, interoperability, and rollback.
What is a quantum-safe cryptography system?
A quantum-safe cryptography system protects information and trust decisions with algorithms, protocols, key management, and migration controls designed to remain secure against both classical and quantum-capable attackers. In practice, the immediate engineering work is post-quantum cryptography: replacing quantum-vulnerable public-key operations while preserving interoperability, authentication, recovery, and service behavior.
Shor's algorithm threatens widely deployed integer-factorization and discrete-logarithm public-key systems if a sufficiently capable quantum computer is built. That does not make every cryptographic mechanism obsolete: symmetric encryption and hashing have different quantum security considerations, and every protocol still needs correct key management and implementation.
Core invariant
Migration is a system transition, not an algorithm rename. Inventory every cryptographic use by purpose and owner, select a standardized replacement for that purpose, prove protocol interoperability and failure behavior, and retain a controlled rollback path until the new trust chain is qualified.
No standards body can supply a universal date for a cryptographically relevant quantum computer. Prioritize with owned facts: data-protection horizon, trust-root lifetime, replacement lead time, protocol reach, and current migration evidence.
Separate the cryptographic jobs before selecting primitives
Confidential channel
Key establishment
Two parties derive a shared secret. NIST FIPS 203 standardizes ML-KEM for this job; a KEM does not authenticate a software release by itself.
Authenticity
Digital signature
A signer authorizes a message that others can verify. FIPS 204 standardizes ML-DSA and FIPS 205 standardizes the hash-based SLH-DSA family.
Data path
Symmetric protection
Encryption and hashing remain part of the design. Review security strength, key length, mode, nonce rules, and retention rather than replacing them blindly with a KEM.
System boundary
Protocol and identity
Certificates, negotiation, key stores, HSMs, libraries, firmware, recovery roots, and counterparties determine whether a standardized primitive can actually ship.
From cryptographic use to controlled cutover
The primitive is one stage in a larger ownership, compatibility, and recovery path.
Discover
Owned inventory
Record algorithm, purpose, key lifetime, protocol, library, location, data horizon, owner, and external dependencies.
Select
Purpose-specific profile
Choose a final standard and parameter set that matches the security and protocol job.
Prove
Interoperable transition
Test negotiated, hybrid, dual-certificate, or dual-root behavior including downgrade, malformed input, mixed versions, and rollback.
Operate
Observed cutover
Canary the new path, measure actual selection and failures, rotate keys, remove obsolete trust only after evidence, and keep the inventory current.
Lab 1: order migration work with evidence
Choose an asset and its current readiness, then add avoidable delay. The lab deliberately does not produce a "quantum risk score" or predict attacker capability. It exposes the facts an engineering program can own: inventory gaps, dependency gates, lead time, classical-only exposure, and rollback readiness.
Turn cryptographic inventory into a migration decision
Load the modeled asset inventory, readiness state, and migration delay.
Loading migration inventory...
Long-lived confidential data deserves early attention because an attacker can retain ciphertext now and attempt decryption later. Long-lived signing roots create a different problem: devices and verifiers may need years of dual-trust support before the old root can be removed safely.
Use the final NIST standards by purpose
NIST published the first three final post-quantum standards on August 13, 2024:
- FIPS 203, ML-KEM defines key generation, encapsulation, and decapsulation for establishing a shared secret.
- FIPS 204, ML-DSA defines a lattice-based digital signature scheme.
- FIPS 205, SLH-DSA defines stateless hash-based digital signatures.
The parameter-set numbers are not interchangeable "key sizes." They identify complete profiles with different public-key, private-key, ciphertext or signature sizes and security categories. Protocol profiles may further restrict which set, mode, or encoding is permitted.
800 + 768 B
ML-KEM-512
Encapsulation key plus ciphertext; FIPS 203 Category 1 parameter set
1,184 + 1,088 B
ML-KEM-768
Encapsulation key plus ciphertext; FIPS 203 Category 3 parameter set
1,312 + 2,420 B
ML-DSA-44
Public key plus signature; FIPS 204 Category 2 parameter set
1,952 + 3,309 B
ML-DSA-65
Public key plus signature; FIPS 204 Category 3 parameter set
The sums are useful envelope checks, not a complete wire-format estimate. A TLS, certificate, package, or firmware protocol adds framing, algorithm identifiers, trust material, retransmission behavior, and application data.
Lab 2: fit the primitive to the protocol envelope
Select a key-establishment or signature workflow, then deliberately choose compatible and incompatible primitives. Change daily volume to see how exact FIPS key, ciphertext, and signature sizes propagate into transport and key-storage pressure.
Match the standardized primitive to the protocol envelope
Load the final NIST primitive sizes and a protocol-specific byte budget.
Loading FIPS byte envelopes...
Passing the byte budget is only the first gate. Benchmark maintained implementations on the target hardware, include certificate and handshake growth, exercise malformed inputs, and confirm that retries or fallback cannot silently downgrade the intended security profile.
Design migration as a sequence of reversible releases
1 Inventory
Build cryptographic visibility
Combine source, configuration, certificate, dependency, runtime, and network evidence. Assign an owner and freshness signal to every material use.
2 Policy
Define profiles and boundaries
Map each purpose to an approved standard, parameter set, library, key store, protocol profile, compatibility range, telemetry, and rollback rule.
3 Interoperate
Prove mixed-version behavior
Test every client, service, device, certificate, HSM, and recovery path that crosses the boundary. Challenge negotiation and downgrade behavior, not only the happy path.
4 Cutover
Canary, rotate, and retire
Roll out by bounded cohort, observe actual algorithm selection, rotate material, drill recovery, and remove old trust only when dependencies and rollback criteria permit it.
Hybrid or dual-stack operation can reduce transition risk, but it also creates more states. Specify exactly how secrets or signatures are combined, which failures abort, how downgrade is detected, and when the classical path can be removed.
Keep inventory and selection policy reviewable
Do not implement cryptographic primitives in application code. Use maintained, reviewed libraries and validated modules where the deployment requires them. Application code should own purpose, profile selection, protocol boundaries, and evidence.
Test the transition, not only the primitive
- reject malformed keys, ciphertexts, signatures, encodings, and algorithm identifiers;
- test mixed old and new clients, services, certificates, devices, and recovery images;
- verify negotiation cannot silently choose an unauthorized classical-only path;
- measure handshake, packet, certificate, storage, CPU, memory, and tail-latency changes;
- rotate, revoke, restore, and roll back key material in realistic key stores and HSMs;
- exercise partial deployment, dependency outage, clock error, and stale trust stores;
- monitor effective algorithm selection and failure reasons without logging secret material;
- update the inventory when libraries, protocols, owners, or standards change.
Primary references
- NIST FIPS 203 specifies ML-KEM and its parameter-set sizes and operations.
- NIST FIPS 204 specifies ML-DSA and its parameter-set sizes and operations.
- NIST FIPS 205 specifies SLH-DSA.
- NIST NCCoE migration guidance organizes current work around cryptographic visibility, risk management, interoperability, and performance.
- NIST IR 8547 initial public draft identifies quantum-vulnerable standards and transition dependencies. It is a draft, so track its status rather than treating every proposed date or change as final policy.