Post-Quantum Encryption on a $5 Microcontroller: Building the Aethyr Edge Node

by Aethyr Engineering
engineeringpost-quantumcryptographyesp32iotedgeopen-sourceawpml-kemblake3

TL;DR — What This Means For You

Every smart device in your life — the thermostat, the doorbell, the security camera — sends your data to someone else's server, encrypted with algorithms that a quantum computer will break. You pay monthly for this privilege and you have no control over where your data goes.

We built an open source firmware that lets a $5 chip talk to a local AI computer with encryption that quantum computers can't break. No cloud. No subscription. No data leaving your house. The sensor in your living room and the AI in your closet speak directly to each other on a private network you own, secured by the same cryptographic standard the US government just adopted for national security.

Example: You buy an ESP32-S3 board for $5 and a Jetson for $200. You flash our firmware. The ESP32 connects to the Jetson over a private WiFi network the Jetson creates — no router needed. In 2.1 seconds, they establish a quantum-proof encrypted channel. Now you have a sensor node that reads temperature, motion, doors, light — whatever you wire up — and feeds it to an AI running locally on the Jetson. The AI makes decisions, controls your home, and learns your patterns. Every packet between them is encrypted. Nobody can read it. Not your ISP, not a hacker on your WiFi, not a government with a quantum computer. And it costs you $205 once, not $10/month forever.

That's what this firmware does. The rest of this post explains how.

Why This Is Personal

In February 2026, Nancy Guthrie — the mother of NBC's Savannah Guthrie — was taken from her home in Tucson, Arizona. As of this writing, she has not been found. The FBI released footage from her Ring doorbell camera showing the suspected kidnapper approaching her front door.

That footage existed because Ring cameras send everything to Amazon's servers. In 2022, Amazon confirmed it had shared Ring footage with police 11 times without user consent. They've since changed their policy, but the architecture hasn't changed — your camera footage still sits on Amazon's servers, accessible to Amazon employees, subpoenable by courts, and vulnerable to breaches.

This isn't an abstract privacy debate. A woman is missing. Her doorbell camera was supposed to protect her. Instead, it recorded her abduction and sent the footage to a corporation's cloud.

The question isn't whether surveillance cameras are good or bad. The question is: who controls the footage?

With the system we built, the answer is you. Your cameras feed into a computer in your home. The footage never leaves your network. There is no server to subpoena because there is no server. There is no employee who can access your feed because the data never reaches a company. The AI that processes the video runs on your hardware, encrypted with cryptography that no one — not a hacker, not a corporation, not a government — can break.

Local-first isn't a technical preference. It's a safety architecture.

The Technical Version

We put post-quantum cryptography on a $5 chip. An ESP32-S3 microcontroller performs ML-KEM-768 key exchange in 9.6 milliseconds, establishes a fully encrypted session with a Jetson Orin Nano in 2.1 seconds from cold boot, and maintains that session with XChaCha20-Poly1305 encrypted frames — every single packet integrity-checked with BLAKE3.

The ML-KEM implementation is formally verified. The firmware has been fuzz-tested with 410,000 iterations and zero crashes. The crypto self-test suite runs 13 tests on every boot. Cross-platform interoperability is proven byte-for-byte between the ESP32's C implementation and our Python server stack.

The firmware is open source. The benchmarks are reproducible. Anyone can flash an ESP32-S3 and verify these numbers.

Why This Matters

NIST published the post-quantum cryptography standards in August 2024. ML-KEM-768 (FIPS 203) and ML-DSA-65 (FIPS 204) are the algorithms the US government mandates for quantum-resistant security. The migration deadline is 2035.

Most PQC implementations target servers and desktops. The question nobody was answering: can these algorithms run on the constrained devices that make up the majority of deployed hardware? IoT sensors, industrial controllers, smart home devices — the billions of endpoints that actually need protection.

We answered it. ML-KEM-768 key generation takes 9.6ms on a 240MHz microcontroller with 520KB of RAM. The full key exchange adds 22ms. That's fast enough for real-time IoT. Whether it's a private home automation system, an enterprise building, or a defense installation — the same chip, the same encryption, the same protocol.

The Architecture

The ESP32-S3 runs as an EDGE tier node in the Aethyr mesh, speaking our custom AethyrWire Protocol (AWP) — a binary framed protocol with a 638-byte header, variable payload, and BLAKE3 checksum on every frame.

ESP32-S3 (EDGE)                    Jetson Orin (NODE)
  ├── WiFi → dedicated AP ────────── 2.4GHz AP hosted by Jetson
  ├── TCP ─────────────────────────── Port 9000
  ├── HELLO (ML-KEM public key) ───→ 
  ←── HELLO_ACK (KEM ciphertext) ──
  ├── KEM decapsulation ──────────── Both derive session key
  ├── BLAKE3 KDF ─────────────────── "awp-session-key" context
  ├── Encrypted auth token ────────→ First encrypted frame
  └── All subsequent frames ──────── XChaCha20-Poly1305

No router in the path. The Jetson hosts a dedicated WiFi AP for the IoT mesh while maintaining its internet connection over ethernet. The ESP32 connects directly to the brain. This architecture is the foundation of the Aethyr platform — local-first AI with security built into every layer.

The Crypto Stack

LayerAlgorithmImplementation
Key exchangeML-KEM-768 (FIPS 203)mlkem-native v1.0.0 — CBMC + HOL-Light formally verified
Frame integrityBLAKE3-256Official C implementation, SIMD disabled for Xtensa
Payload encryptionXChaCha20-Poly1305HChaCha20 + mbedTLS ChaCha20-Poly1305
Key derivationBLAKE3 derive_keyContext: "awp-session-key"
Nonce persistenceESP32 NVS flash+1000 gap per boot, periodic flush

We started with the pqcrystals/kyber reference implementation and later swapped to mlkem-native. The swap cost 1,802 bytes of flash (+0.22% of the total image) and gained formal verification plus 20% faster execution. Free upgrade.

What this means: Every message between devices is encrypted with algorithms designed to survive quantum computers. The encryption library has been mathematically proven to be correct and to not leak information through timing. The entire security layer adds less than 2KB to the firmware — smaller than this paragraph.

The Benchmarks

Statistical Timing (50 iterations)

OperationMeanStdDevMinMax
BLAKE3 (1KB)255us102us238us969us
ML-KEM keygen9,052us164us8,986us9,558us
ML-KEM encap10,070us11us10,058us10,146us
ML-KEM decap12,197us11us12,192us12,275us
XChaCha20 encrypt243us46us235us564us
BLAKE3 KDF49us60us40us472us
AWP frame enc+dec363us95us346us1,030us

ML-KEM encapsulation and decapsulation show 11 microseconds of standard deviation across 50 iterations. That's less than 0.1% variance — consistent with the constant-time guarantees from the formal verification.

What this means: The key exchange takes about 10 milliseconds — one hundredth of a second. It takes the same amount of time every single time, which is important because if it varied, an attacker could learn information by measuring how long it takes. We ran every operation 50 times to prove the consistency.

Boot-to-Encrypted Timeline

MilestoneTime
CPU start273ms
ML-KEM-768 keypair generated442ms
WiFi connected (direct AP)774ms
TCP connected to Jetson1,887ms
HELLO sent (2,530B with KEM key)1,890ms
HELLO_ACK received2,082ms
Session key derived (KEM decap + BLAKE3 KDF)2,116ms
First encrypted frame sent2,121ms

Cold boot to post-quantum encrypted session: 2.1 seconds.

For comparison, most commercial IoT devices take 10-30 seconds to boot and connect to WiFi. None of them have post-quantum encryption.

What this means: Plug in the device, and in two seconds it's talking to the brain with military-grade encryption. Your smart light bulb takes longer to connect to WiFi alone.

Stack Usage

OperationPeak Stack
ML-KEM keygen14,564 bytes
ML-KEM full cycle (keygen + encap + decap)18,812 bytes
XChaCha20 encrypt + decrypt5,236 bytes
BLAKE3 (1KB hash)4,228 bytes
Production connection task (full handshake + message loop)37,972 bytes

Minimum safe task stack for ML-KEM operations: 24KB. The production connection task runs at 49KB with 23% headroom under live load.

What this means: Post-quantum cryptography is computationally expensive. We measured exactly how much memory each operation needs on this chip and verified it doesn't run out under real-world conditions. The system has a 23% safety margin during normal operation.

Memory Footprint

ComponentFlash (.text)Flash (.rodata)
mlkem-native (ML-KEM-768)10,831 bytes448 bytes
BLAKE317,170 bytes64 bytes
Total firmware832,712 bytes

The entire firmware — protocol, crypto, WiFi, sensors, self-tests — fits in 832KB. 21% of the 1MB app partition is free.

What this means: Everything — the communication protocol, the quantum-proof encryption, the WiFi stack, the sensor drivers, and the self-test suite — fits in less than a megabyte. There's room left over for future features.

Security Hardening

Building the crypto primitives is the easy part. Making the system resistant to real attacks is the hard part. Here's what we addressed:

Nonce reuse on reboot. The encryption counter is persisted to flash and jumps forward on every boot. No nonce is ever reused, even on power loss.

Downgrade attack. If someone strips the encryption from the handshake, the ESP32 refuses to connect. No fallback to plaintext.

Timing side channel. A failed key exchange takes identical time to a successful one. No information leaks through response timing.

Node impersonation. After encryption is established, the ESP32 proves its identity with a token that can only be computed by the session key holder.

What this means: We didn't just add encryption — we thought about how someone would try to break it. Can they force the device to talk without encryption? No, it refuses. Can they learn something by measuring how long the device takes to respond? No, every response takes the same time. Can they pretend to be a legitimate device? No, every device proves its identity after connecting. These aren't theoretical concerns — they're the attacks that real adversaries use against IoT devices today. For organizations with strict security requirements, see our compliance and defense pages.

What We Proved

13 self-tests run on every boot. If any fail, the firmware halts. It does not proceed to network operations with broken crypto. The tests cover BLAKE3 (official test vectors), XChaCha20-Poly1305 (round-trip, tamper detection, wrong key rejection, nonce uniqueness), ML-KEM-768 (keygen, encap/decap round-trip, wrong key rejection), cross-platform interoperability (BLAKE3 KDF match, Python ciphertext decryption), and AWP frame integrity.

410,000 fuzz iterations with zero crashes. The frame decoder was tested with random bytes, valid headers with garbage payloads, random TCP chunks, truncated frames, single bit-flips, and extreme length values. AddressSanitizer and UndefinedBehaviorSanitizer found zero violations. The BLAKE3 checksum caught 100% of single-bit corruptions across 100,000 bit-flip tests.

Cross-platform interoperability proven byte-for-byte. The ESP32's BLAKE3 KDF produces identical output to Python's blake3 library. The ESP32 successfully decrypts ciphertext produced by Python's cryptography library with the same HChaCha20 + ChaCha20-Poly1305 construction.

What this means: The device tests its own cryptography every time it turns on. If anything is wrong, it stops and refuses to operate — it won't send a single message with broken encryption. We threw 410,000 random garbage inputs at the message parser and it didn't crash once. And we proved that the $5 chip and the server encrypt and decrypt identically — a message encrypted by one can be read by the other, and vice versa, with zero differences.

The Bigger Picture

This ESP32 firmware is one piece of a larger system. In the Aethyr mesh, AI agents teleport between physical machines — their entire cognitive state serialized, signed with ML-DSA-65, transmitted over AWP, verified on arrival, and reconstructed. A full three-hop teleportation across three machines and two CPU architectures completes in 341 milliseconds.

The full DIDComm-composed handshake — DID generation, credential issuance, credential verification, ML-KEM-768 key exchange, session key derivation — completes in 1.4 milliseconds server-side. That's 107 complete handshakes in a single eye blink.

The ESP32 is the sensory edge of this system. It connects sensors and actuators to the mesh, secured with the same post-quantum cryptography that protects agent-to-agent communication between servers. One protocol from cloud to microcontroller.

What this means: The sensor in your building and the AI running in a datacenter speak the same language with the same security. An AI agent can move its entire mind between machines in a third of a second — taking its memory, personality, and skills with it. The complete identity verification between two agents takes 1.4 milliseconds. A human blink is 150 milliseconds. We do 107 complete verifications in that time.

Open Source

The ESP32 AWP edge node firmware is open source:

github.com/aethyrai/esp32-awp-edge

The repository includes the complete firmware source, the BLAKE3 and mlkem-native component integrations, the crypto self-test suite, the fuzz testing harness, the statistical benchmarks, and the demo script. Flash it on an ESP32-S3, configure the WiFi and upstream address, and you have a post-quantum encrypted IoT node.

We used publicly available, audited cryptographic primitives:

  • BLAKE3 — official C implementation
  • mlkem-native — formally verified ML-KEM
  • mbedTLS ChaCha20-Poly1305 — shipped with ESP-IDF

We didn't invent the algorithms. We proved they work on a $5 chip, wired them into a real protocol, hardened the implementation against real attacks, and published the numbers.

What's Not Open Source

The Aethyr agent operating system — the AWP protocol semantics, the agent teleportation system, the holonic multi-agent hierarchy, the DID/SSI identity layer, the HDC-based routing, and the cognitive vector architecture — remains proprietary. The ESP32 firmware is a client that speaks the protocol. It doesn't define it. To learn more about the full system, see the platform overview or request a demo.

Try It

Requirements: an ESP32-S3 board ($5-15), a USB cable, and ESP-IDF v5.4.

git clone https://github.com/aethyrai/esp32-awp-edge
cd esp32-awp-edge
idf.py menuconfig     # Set WiFi SSID/password and upstream IP
idf.py build
idf.py -p /dev/ttyUSB0 flash monitor

Watch the serial output. You'll see the ML-KEM keypair generate in 13ms, the self-tests pass in 226ms, and the PQC handshake complete in under 250ms. That's post-quantum security on hardware you can buy for the price of a coffee.


Aethyr is building the operating system for autonomous AI agents. Post-quantum secure. Local-first. No cloud required. Learn about Aethyr for your home, your enterprise, or your mission. aethyr.cloud