Post-quantum cryptography and crypto agility
A device you ship in 2026 will still be in a factory cell, a kiosk, or a vehicle in 2036. The cryptography you baked into it will not have aged as well.
That is the whole post-quantum problem for edge devices, in one sentence. It is not about quantum computers existing tomorrow, but it’s about the gap between how long our cryptography stays valid and how long your hardware stays deployed.
Where post-quantum comes from
In 1994, Peter Shor showed that a sufficiently large quantum computer could factor integers and solve discrete logarithms in polynomial time. It basically removed the hard problem allowing RSA, Diffie-Hellman, and elliptic-curve cryptography to exist in the first place.
Symmetric cryptography, as well as hashing functions, survives in much better shape. Grover’s algorithm gives a quadratic speedup on brute-force search, which effectively halves key strength: AES-256 retains about 128 bits of security against a quantum attacker.
Our AES-256 payload encryption is already post-quantum. Our signatures and key exchange are not. That asymmetry is the shape of everyone’s migration.
NIST ran an open competition from 2016 to select replacements, and finalized the first three standards in August 2024:
- FIPS 203 — ML-KEM (aka Kyber), a key-encapsulation mechanism to replace Diffie-Hellman and ECDH.
- FIPS 204 — ML-DSA (aka Dilithium), the general-purpose signature scheme.
- FIPS 205 — SLH-DSA (aka SPHINCS+), a hash-based signature scheme — conservative, well-understood, and much larger.
These are built on lattice problems (and, for SLH-DSA, on hash functions alone) that no known quantum algorithm breaks.
Why “later” is the wrong answer
The famous argument for urgency is harvest now, decrypt later: an adversary records encrypted payloads today and decrypts it once a cryptographically relevant quantum computer exists.
It applies to us quite directly. In our system, the encrypted model is AES-256 — fine. But the per-device key delivery wraps the content key using ECDH on P-256.
An attacker who captures a device’s key box and the ciphertext today, and waits, could recover the content key later and decrypt a model they archived years earlier.
The real deliverable is crypto agility
What matters the most right now is cryptographic agility - the ability to change algorithm without redesigning the system around it.
Crypto agility may sound is unglamorous, and completely contradictory to cryptography in the first place, but what it entails is more sound that it looks.
Quite directly, it means to be able to shift an algorithm without changing the system. But it also means that systems need to be flexible enough to also accomodate for different settings.
For instance, the keysize should not be baked in. E.g. a P-256 public key is 64 bytes; an ML-DSA-65 public key is about 1.9 KB, and its signature about 3.3 KB rather than 64 bytes.
Agility also means being honest about what is not agile. The trust anchor compiled into a kernel module can only be changed by shipping a new kernel module — so on our platforms, the firmware update path is the migration path.
Cosign is already moving
As mentioned in an earlier blog post, we are big fans of Sigstore and Cosign.
Sigstore has been experimenting with post-quantum signing, and has added ML-DSA to its protocol-buffer specification.
There is active work (including a Trail of Bits review of cryptographic agility in Sigstore) on making the whole ecosystem algorithm-flexible rather than P-256-shaped. Hybrid approaches, carrying a PQC key and signature alongside the classical ones in the same certificate, are being prototyped.
One practical brake worth flagging: KMS and HSM support is uneven. Our entire key-custody story depends on the private key living in a cloud KMS or a local HSM, and not every vendor can generate and sign with ML-DSA keys yet. Adoption will be gated by that at least as much as by the standards.
What we will have to build
When cosign can emit PQC signatures, our work is to extend cosign-verify (our freestanding C verifier that runs inside our system) to check them. That is a much smaller job than designing a scheme, but it is not free, and the interesting parts are all about size.
An ML-DSA verifier is a bigger piece of code than a 64-byte ECDSA check, and it has to keep the properties that let ours live in a kernel module: no libc, no allocation, no RNG.
Signatures and keys grow by roughly fifty times, which matters more on embedded targets than anywhere else. Constraints like that are exactly why we are working following PQC adoption right now, rather than in 2030.
The key delivery has its own migration: the ECDH inside our per-device box becomes ML-KEM, most likely in hybrid form first, since a hybrid construction stays as strong as the better of its two halves.
None of this is urgent for us right now, but all of work is cheaper if the system build is made to expect the change. Which is the entire point of doing agility work before you need it !