A cipher for devices that can’t spare the memory, and can’t afford a lost packet.
APEX-256 is a 256-bit stream cipher for microcontrollers. No heap. No lookup tables. No branches in the keystream path. Ciphertext comes out exactly as long as the plaintext, so a message that fit in one packet still fits in one packet. We run it on real boards with a power meter on the bench, and we are plain about what is proven and what isn’t.
Small chips, long lives, no room for overhead
Walk through a plant, a pump station, or your own house. Gas sensors. Water meter shut-offs. Power cut-offs. Relays that move a lever. Most of them run on a microcontroller with very little memory, and plenty sit on a coin cell that is supposed to last for years in the heat.
A cipher that needs a big table, a heap, or three packets to deliver one message is the wrong cipher for that board. Lose one packet and the message is gone. Resend it, and the battery pays.
Nobody is going to tear those devices out and replace them. So the encryption has to fit what is already there.
The longer story is on the About page.
Four things we built it around
No heap
40-byte self-contained context
Operates inside a 40-byte self-contained instance context. Zero heap allocation, zero static .bss, no malloc, no free, nothing to fragment and nothing to run out of.
One message, one packet
Ciphertext = plaintext length
It is a stream cipher, so output is exactly as long as input. Supports standard 64-bit nonces, extended 256-bit (X256) nonces, 256-byte forward-secrecy ratcheting, and 4x to 8x fast multi-byte extraction. Authentication is a separate layer; see How It Works.
Constant-time
Same cycles, every byte
No data-dependent branches, no lookup tables in the keystream path, and hardware side-channel hardening (CPA |r| = 0.0024, Welch |t| = 0.74 < 4.50). Power and EM behavior we measure on the bench. We do not claim immunity.
Target silicon
ARM Cortex-M • ESP32 • RISC-V • FPGA
Run and measured on Cortex-M4/M7, ESP32-S3, nRF52840, RISC-V, and synthesizable Verilog-2005 RTL. Power capture logs ship with the evaluation kit.
Before you evaluate it
The core APEX-256 stream mode encrypts with zero byte expansion; for authenticated encryption, pair it with the companion APEX-AEAD / AEAD-X256 / AEAD-W64 Encrypt-then-MAC mode or a NIST standard AEAD like ASCON-128. It is not a NIST standard. And nobody outside our lab has published an attack or a review of it yet. We would like that to change.
Where to go next
Hardware
What it runs on, how we measure it, and what we haven’t published yet.
View Silicon Profiles →How It Works
One key exchange, then a stream. Where post-quantum protection actually lives.
See the Workflow →Architecture
40-byte self-contained zero-allocation context, hardware side-channel hardening, X256 nonces, ratcheting, and a 24-round init.
Inspect the Design →Validation & SMT Proofs
16 cryptanalysis waves, 38 formal/SMT/SAT/MILP/SCA tools, 4.0x to 24.0x security margin, 32 TB of PractRand, and BigCrush.
Review the Results →Applications
Utilities, meters and shut-offs first. Then industrial controls, tactical sensors, drones and satellites.
Explore Use Cases →About
Why this exists, who builds it, and the lab it is tested in.
Read the Story →Also: FAQ • Glossary • APEX-256 with ASCON • Field Notes • Licensing
The reference SDK (apex256_nano.h), the Z3 proof scripts, and the power capture logs are available under an evaluation NDA.