When NIST finalized the first post-quantum cryptography standards in 2024, the focus was overwhelmingly on servers, browsers, and cloud infrastructure. Embedded systems were an afterthought—if they were considered at all. Yet the IoT landscape presents a unique challenge: billions of devices with limited RAM, modest CPUs, and long deployment lifecycles that will still be operational when quantum computers become a practical threat.
The Embedded PQC Challenge
Post-quantum algorithms like ML-KEM (Kyber) and ML-DSA (Dilithium) were designed for servers and workstations. Their memory footprints and computational requirements seemed incompatible with microcontrollers. A typical ML-KEM key encapsulation might require hundreds of kilobytes of RAM for intermediate calculations—more than many microcontrollers have in total.
This is what makes the Aethyr Edge Node firmware notable. It demonstrates that NIST-standardized post-quantum cryptography can run on an ESP32-S3—a chip that costs around $3 and packs just 512KB of SRAM. The implementation uses:
- ML-KEM-768 — The NIST FIPS 203 standard for quantum-resistant key exchange
- BLAKE3 — Modern hash function with excellent performance on embedded targets
- XChaCha20-Poly1305 — Authenticated encryption with 24-byte nonces
Performance Reality Check
The benchmarks reveal something unexpected: post-quantum operations on a 240 MHz ESP32-S3 are fast enough for real-world applications.
| Cryptographic Operation | Latency | Practical Implication |
|---|---|---|
| ML-KEM key generation | ~9 ms | One-time cost at session setup |
| ML-KEM encapsulation | ~10 ms | Client-side operation |
| ML-KEM decapsulation | ~12 ms | Server-side operation |
| Full handshake | ~35 ms | Comparable to TLS 1.3 |
For context, a typical TLS 1.3 handshake takes 20-50 milliseconds on the same hardware. Post-quantum key exchange adds modest overhead—noticeable, but not prohibitive.
Memory usage is equally encouraging: the firmware occupies 833KB of flash and leaves 157KB of heap available at runtime. This leaves room for application logic, sensor data buffering, and TinyML models.
Security Engineering Decisions
The implementation reflects careful security engineering:
- Formally verified ML-KEM — The key exchange algorithm has undergone formal verification, providing mathematical assurance of correctness
- Constant-time operations — Critical paths avoid timing side-channels
- Extensive fuzzing — 410,000 iterations with AddressSanitizer, zero crashes
- Fault injection testing — 100,000 single-bit-flip tests, all detected
- Boot-time self-tests — 13 cryptographic verification tests run at every startup
These are the kinds of security practices typically reserved for high-assurance systems, not IoT firmware. They reflect the reality that post-quantum cryptography is new enough that implementation bugs are a greater risk than algorithm weaknesses.
The Aethyr Context
The firmware is part of Aethyr Research’s broader project: a distributed agent mesh where AI agents run across heterogeneous nodes. ESP32-S3 devices handle edge inference while larger machines (NVIDIA Jetson, in their reference architecture) handle complex reasoning. The cryptographic layer secures communication between nodes in this mesh.
Currently, only the ESP32-S3 firmware is open source. The upstream node software and complete system documentation remain proprietary. This limits the firmware’s immediate utility as a standalone solution, but its value as a reference implementation is substantial.
Implications for Embedded Developers
What does this mean for developers building IoT systems today?
Start planning now. The “harvest now, decrypt later” attack model means data captured today could be decrypted once quantum computers mature. Systems with long confidentiality requirements need quantum-resistant protection before deployment.
The hardware barrier is lower than expected. If a $3 microcontroller can perform post-quantum handshakes in 35ms, most IoT hardware can handle it. The question is no longer “can we afford PQC?” but “how do we integrate it?”
Implementation quality matters. Post-quantum algorithms are still new. Verified implementations with comprehensive testing—like this one—are more valuable than untested ports of reference code.
Building the Firmware
For developers wanting to experiment:
git clone https://github.com/aethyrai/esp32-awp-edge
cd esp32-awp-edge
idf.py menuconfig # Configure WiFi and upstream node
idf.py build
idf.py -p /dev/ttyUSB0 flash monitorThe firmware requires ESP-IDF v5.4+. On boot, you’ll see 13 self-tests execute before any network activity begins—a good pattern for security-critical firmware.
Looking Forward
This implementation proves that post-quantum cryptography is viable on resource-constrained hardware. The remaining challenges are ecosystem-level: integrating PQC into existing IoT protocols (MQTT, CoAP, LwM2M), updating certificate infrastructure, and building key management systems for quantum-resistant identities.
The cryptographic primitives are ready. The engineering work now begins.
Resources
- GitHub Repository: github.com/aethyrai/esp32-awp-edge
- NIST FIPS 203 Standard: csrc.nist.gov/pubs/fips/203/final