Abstract
Key Points at a Glance
- Key exchange messages get much larger: ML-KEM key shares are typically ~1–2 orders of magnitude larger than elliptic-curve key shares (e.g., ML-KEM-768 public key 1,184 bytes vs X25519 32 bytes). [1][2]
- Certificates and signatures grow too: ML-DSA public keys and signatures are in the kilobyte range, which can noticeably increase certificate chains and firmware-signature overhead. [3]
- Compute can be viable on modern MCUs: optimized Cortex-M4 code reports single‑digit millisecond ML-KEM operations, but radio payload limits can dominate total cost. [4][5]
- Hybrid modes are the practical migration strategy: pairing a classical ECDH share with ML-KEM can give quantum resistance while keeping a safety net during rollout. [6][7]
- Plan for memory and protocol friction: the hardest problems on constrained devices are often RAM/flash budgets, fragmentation, and update logistics—not raw CPU time. [5]
The IoT Challenge: Why PQC Hits Different
NIST standardized its first post-quantum public-key algorithms as Federal Information Processing Standards (FIPS) in August 2024: ML-KEM for key establishment and ML-DSA for signatures. [7][3] Those standards target general-purpose systems, but IoT sits at the opposite extreme: microcontrollers with ~256 KB of flash, ~64 KB of RAM, strict energy budgets, and network links with small maximum transmission units.
Classical elliptic-curve cryptography fits constrained devices partly because its on-the-wire artifacts are small. In TLS 1.3, an X25519 key share is 32 bytes and a P-256 key share is typically 65 bytes (uncompressed point). [2][6] By comparison, ML-KEM-768 uses a 1,184-byte encapsulation public key and a 1,088-byte ciphertext. [1] The shift is not just “bigger numbers”: it changes handshake framing, buffer sizing, and often forces fragmentation on low-MTU links.
Sizing Up the Algorithms
| Algorithm | Public Key | Ciphertext / Signature | Security Level |
|---|---|---|---|
| ECDH P-256 (TLS 1.3 key share) | 65 B | — | ~128-bit |
| X25519 (TLS 1.3 key share) | 32 B | — | ~128-bit |
| ML-KEM-512 | 800 B | 768 B | NIST Level 1 |
| ML-KEM-768 | 1,184 B | 1,088 B | NIST Level 3 |
| ML-KEM-1024 | 1,568 B | 1,568 B | NIST Level 5 |
| ECDSA P-256 (X.509/TLS) | 65 B | DER-encoded (variable) | ~128-bit |
| ML-DSA-44 | 1,312 B | 2,420 B | NIST Level 2 |
| ML-DSA-65 | 1,952 B | 3,309 B | NIST Level 3 |
| ML-DSA-87 | 2,592 B | 4,627 B | NIST Level 5 |
The table reveals a practical reality: key-establishment traffic alone can be a couple of kilobytes per handshake. On constrained networks, that can dominate everything else. For example, LoRaWAN maximum application payload sizes depend on region and data rate; in EU863–870, RP002-1.0.3 shows payload limits as low as 51 bytes at the slowest data rates and up to 222 bytes at higher data rates—so multi-packet handshakes and careful fragmentation become mandatory. [5]
Benchmarks on Real Hardware
Fortunately, the performance story is more nuanced. Optimized implementations, especially those leveraging ARMv7-M DSP instructions, deliver impressive throughput:
- Cortex-M4 @ 168 MHz (STM32F446, wolfSSL): Kyber768 key generation ~6.9 ms, encapsulation ~8.5 ms, decapsulation ~9.1 ms (single core, -Ofast). [4]
- Same platform (wolfSSL, classical baseline): ECDHE P-256 agreement ~18.1 ms; wolfSSL notes that a full NIKE-style exchange effectively doubles work across both endpoints, yielding ~26.7 ms total for the key exchange. [4]
- Interpretation for IoT: ML-KEM can be compute-competitive, but message size and buffering frequently become the limiting factor on low-MTU links and tiny RAM budgets. [1][5]
Timing depends heavily on implementation choices (constant-time hardening, memory layout, and whether optimized assembly is available). Treat published benchmarks as indicative, then measure on your exact MCU, compiler flags, and radio stack. For algorithm sizes and parameter sets, the most stable public references are the NIST FIPS documents and the Open Quantum Safe parameter tables. [7][1]
Strategies for Constrained Devices
1. Choose the Right Security Level
NIST Level 1 (ML-KEM-512) may suffice for short-lived sessions or sensor data that loses value within days. Reserve Level 3 or 5 for long-term secrets like device identity keys.
2. Offload to a Secure Element
Secure elements can help by isolating long-term keys and by providing hardened, side-channel-resistant implementations. Whether they accelerate PQC specifically varies widely by vendor and generation, so treat this as a roadmap item: verify what is actually implemented in silicon (and what is only available as host-side software) before making architectural assumptions.
3. Hybrid TLS: Best of Both Worlds
Hybrid key exchange—combining a classical ECDH share with ML-KEM—can give you a conservative migration path: even if one component later weakens, the combined exchange can still provide confidentiality. In practice, hybrid modes increase both message sizes and RAM pressure, so the main engineering work is often on handshake framing, fragmentation, and certificate-chain budgets, not on CPU cycles alone. [6][1]
4. Compress Where Possible
Research into compressed lattice representations (e.g., NTRU-based schemes or future NIST rounds) may further shrink payloads. For now, protocol-level compression (CBOR, CoAP block transfers) and caching certificates on first contact can mitigate bandwidth pain.
The Firmware Update Problem
IoT devices often receive signed firmware images. Today's ECDSA signature is 64 bytes; ML-DSA-65 pushes that to 3.3 KB. For a 256 KB firmware image, the overhead is manageable. But for frequent delta updates of a few kilobytes, a signature larger than the payload itself creates friction.
Solutions under exploration include using different signature families for different roles (for example, keeping fast, compact signatures for frequent delta updates while reserving heavier signatures for infrequent root-key operations). Hash-based signatures such as SLH-DSA (standardized by NIST and based on SPHINCS+) are attractive for their conservative assumptions, but they typically have much larger signatures than ML-DSA—so they do not automatically reduce update overhead on constrained links. [8]
What You Can Verify Today
- The standards are stable: NIST’s ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are finalized and published (August 2024). [7][3]
- The “cost center” is often networking: LoRaWAN payload ceilings can be as low as tens of bytes at slow data rates, making fragmentation unavoidable for PQ handshakes. [5]
- Measure, don’t assume: published MCU benchmarks are useful, but performance and memory use depend strongly on constant‑time hardening and implementation strategy. [4]
If you want this article to stay accurate over time, the safest practice is to anchor “hard numbers” to primary sources (FIPS/RFC/specs) and to vendor benchmark posts that state their test setup.
References
- Open Quantum Safe (liboqs): ML-KEM parameter set summary (sizes and NIST levels)
- RFC 7748: Elliptic Curves for Security (X25519 / X448)
- NIST FIPS 204 (Final): Module-Lattice-Based Digital Signature Standard (ML-DSA)
- wolfSSL: Post-Quantum Kyber Benchmarks (ARM Cortex-M4, STM32F446 @ 168 MHz)
- LoRa Alliance RP002-1.0.3: LoRaWAN® Regional Parameters (payload-size tables by region/data rate)
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- NIST FIPS 203 (Final): Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- NIST FIPS 205 (Final): Stateless Hash-Based Digital Signature Standard (SLH-DSA)
Takeaways for Embedded Engineers
- Start inventorying cryptographic usage now. Know where keys are generated, stored, and exchanged.
- Prototype with liboqs or pqcrypto-embedded. Measure real performance on your target MCU before committing.
- Select hybrid configurations for your next product generation—they're safer and increasingly supported.
- Budget for larger certificates and handshakes. Radio stack, power consumption, and latency estimates need updating.
- Track secure-element roadmaps. Hardware offload will be the smoothest path for deeply constrained devices.
Next Step
Curious how PQC compares to Quantum Key Distribution for IoT? Our deep-dive explains the differences and when each makes sense.
Read: PQC vs QKD →