The term on this page
- PQCpost-quantum cryptography
- algorithms that run on ordinary computers and are believed to resist quantum attack
Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ECCECCelliptic curve cryptographyElliptic curve cryptography: the family of public-key algorithms whose security rests on the difficulty of the elliptic curve discrete logarithm problem.Read the full entry (new tab), ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry (new tab), ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab) are defined in the glossary.
Read this first
The IETF PQUIP working group's constrained-device PQC guidance is now in IESG Evaluation for the 22 October 2026 telechat. The draft treats migration as a resource problem as much as an algorithm problem: a straightforward ML-KEM-768 working set is about 9 KB in its example, ML-DSA-87 signing needs at least 79 KB before per-iteration vectors, and firmware trust anchors must migrate too. It is still an Informational Internet-Draft, not a final RFC.
The current IETF draft covers a part of post-quantum migration that disappears in server benchmarks: devices with small RAM, limited flash, secure elements, TPMs and small HSMs. The Datatracker places revision 08 in IESG Evaluation and on the 22 October telechat agenda. It also still records a revised Internet-Draft as needed, so this is progress through review, not a finished standard.
That distinction matters for a PQC migration roadmap. A library supporting ML-KEM or ML-DSA does not prove the target device can hold the working set, generate keys inside its secure boundary, survive signing-time variance or authenticate a future firmware image. Those constraints belong in the cryptographic inventory before a rollout is scheduled.
Memory pressure is measurable
| Operation | Straightforward representation | Optimization shown in the draft |
|---|---|---|
| ML-KEM-768 working set | About 9,216 bytes for matrix A plus t, s and e | Lazy expansion example reduces the live set to about 2.5 KB |
| ML-DSA-87 signing | At least 79 KB before per-iteration vectors | Lazy expansion and packed private-key vectors can reduce the working set |
| ML-DSA signing runtime | Rejection sampling makes duration probabilistic | Benchmark distributions and tail latency, not one timing sample |
The draft's ML-KEM-768 example counts a 4,608-byte public matrix and three 1,536-byte polynomial vectors, for 9,216 bytes in a straightforward representation. Its lazy-expansion example keeps one matrix polynomial, one secret polynomial and the output vector live at once, about 2.5 KB. The point is not that every implementation will use those exact numbers. It is that peak memory becomes a migration acceptance criterion, especially when the cryptographic module has less RAM than the host around it.
A benchmark average can hide the failure mode
ML-DSA signing uses rejection sampling. The draft shows that ML-DSA-65 needs 22 iterations to reach a 99 percent probability of completion even though the expected count is about 5.1. A device that passes one fast signing test can still miss a watchdog or latency budget in the tail. Benchmark the distribution and the system timeout together.
Seed storage saves space but moves the trust boundary
ML-KEM and ML-DSA can retain a seed and derive expanded private material when needed. That can reduce persistent storage, but the seed is itself a critical security parameter. The draft says it must receive the same protection as a private key and warns that an expanded key cannot be reversed back into the seed if the seed was discarded. A seed-only design therefore affects backup, import, recovery and HSM replacement, not just storage capacity.
- Record whether each device stores a seed, an expanded private key, or both.
- Measure the time and peak RAM needed to derive keys on demand inside the actual secure element or HSM.
- Define how seeds or private keys are backed up and exported before hardware end of life.
- Protect exported Level 5 material such as ML-KEM-1024 or ML-DSA-87 at an equivalent symmetric strength, which the draft maps to AES-256.
- Treat key import as an interoperability path of its own because seed-based and expanded-key formats are not interchangeable.
Those checks fit naturally into an implementation audit. They also change procurement: a secure element that can store today's ECC key may still fail the post-quantum design because it cannot derive, cache or erase the larger state within the required timing and memory budget.
Firmware verification is part of the migration
The draft also makes firmware updates explicit. A field device that moves its network handshake to post-quantum cryptography but still accepts firmware signed only with RSA or ECDSA keeps a future trust failure in its update path. The document points to the SUIT firmware architecture and discusses ML-DSA, SLH-DSA and stateful hash-based signatures as relevant tools for firmware authentication.
This is why crypto agility on embedded systems cannot mean only a configurable TLS group. The boot chain, firmware verifier, attestation key, update format and recovery image all need an algorithm-change path. A migration engagement should test the update mechanism before the device fleet reaches a point where physical replacement is the only fallback.
What teams can do before the draft becomes an RFC
- Use revision 08 as engineering guidance, not as a final interoperability contract.
- Add RAM, flash, signing-tail latency and secure-storage capacity to the device inventory.
- Test key generation, signing, verification, export and zeroization on the actual hardware boundary rather than a desktop build of the same library.
- Exercise the firmware-update path with post-quantum signature sizes and recovery images.
- Keep algorithm identifiers, private-key formats and protocol behavior pinned to the specific standards or drafts used in each test.
A conformance test can prove an ML-KEM or ML-DSA implementation follows its algorithm specification. It cannot by itself prove the product has enough memory, preserves its timing guarantees or can still recover after a firmware-signing migration. Constrained-device readiness needs both layers of evidence.
References
- IETF draft-ietf-pquip-pqc-hsm-constrained-08. Current constrained-device PQC guidance, memory examples, seed management, signing performance and firmware-update considerations.
- NIST FIPS 203. ML-KEM standard and internal key-generation interfaces referenced by the draft.
- NIST FIPS 204. ML-DSA standard, including signing behavior and seed-derived key material.
- IETF RFC 10024. Hybrid ECDHE and ML-KEM key agreement for TLS 1.3, referenced for post-quantum secure transfer channels.
- IETF RFC 9019. Firmware update architecture for IoT devices, referenced by the draft's firmware-authentication section.
Where this goes next