Tricking Kyber Into Trusting Anything: A New Fault Attack on a Post-Quantum Standard
Quantum computers, when they arrive at scale, will be able to break almost all the encryption the internet currently runs on. In response, governments and standards bodies have spent the last several years picking new encryption schemes designed to resist even a quantum computer. The winner for general-purpose encryption is called ML-KEM — better known by its original name, Kyber — and it’s now an official US NIST standard (FIPS 203), already being rolled out in browsers, VPNs, and chips around the world.
Our new paper, Default Correct: A New Fault Surface in the Comparison Booleanisation of Kyber-KEM, shows that a real Kyber chip can be tricked, with nothing more exotic than a well-timed electrical glitch, into accepting a ciphertext it was supposed to reject — and that doing so hands an attacker the device’s entire secret key.
A lock that’s supposed to check the key
Here’s the part of Kyber that matters for this story. Encryption schemes like Kyber don’t just decrypt a message and trust it — they also double-check their own work. When a Kyber chip receives an encrypted message (a ciphertext), it decrypts it, re-encrypts what it just decrypted, and compares the result against the ciphertext it originally received. If the two match, the message is genuine and the chip proceeds. If they don’t match, the chip is supposed to refuse — quietly discarding the result instead of handing anything useful back to whoever sent the bad ciphertext.
This “decrypt, then double-check” step exists specifically to stop attackers from probing the chip with malformed ciphertexts to fish out secrets. It’s the single lock standing between a well-formed request and a forged one. If you can make that lock always say “yes,” the rest of the security proof doesn’t matter.
Where we found the crack
Naturally, that comparison has already been a target for attackers, and defenders have already patched the obvious weak point: the very last step, where the chip decides whether to hand back the real key or a decoy. A well-known defense (by Xagawa et al.) hardens exactly that last step, so that even if an attacker manages to skip it, the chip defaults to handing back nothing useful.
What we found is that the comparison isn’t really one step — it’s a short pipeline of several. Before the chip reaches that final, well-guarded step, it first has to boil down its whole ciphertext comparison into a single yes/no flag — a stage called Booleanisation. That earlier stage had never been specifically examined as its own target before.
It turns out a single, precisely timed clock glitch — a tiny electrical hiccup injected right as the chip is computing this flag — can flip it from “these don’t match” to “these match,” before the final, hardened step ever sees it. The hardened last step then does exactly what it’s designed to do: it faithfully hands back the real key — because, as far as it can tell, the comparison legitimately passed. The defense isn’t broken; it’s just never consulted, because the lie was already told one step earlier.
Not a thought experiment — real hardware, real keys
We didn’t just simulate this. We ran it on an actual ARM Cortex-M4 chip (the same family used in countless embedded and IoT devices), using a low-cost, commercially available glitching tool called a ChipWhisperer — no exotic lab equipment, no decapsulating the chip, no laser. Just a $100-ish device clipped onto the target’s clock line, on the de.ci.phe.red Lab’s recently constituted fault injection analysis setup, funded by the National Quantum Mission.
With this, we repeatedly nudged the chip into falsely accepting crafted ciphertexts, and used those accept/reject answers to reconstruct the device’s secret key one piece at a time — a well-established technique once you have a chip willing to tell you “yes” when it should say “no.” We recovered the complete secret key for all three official Kyber security levels (512, 768, and 1024), each in a single, uninterrupted run on the device.
Crucially, this wasn’t a fluke of one sloppy implementation. We reproduced it across three independent, widely used Kyber code bases and every standard compiler optimization setting — 36 configurations in total — and it worked on every single one, every one of which already had the “official” defense enabled.
Should you be worried?
Mostly not, for now — and it’s worth being precise about why. This attack needs an adversary who has the device physically in hand and can interfere with its clock signal directly. It is not something that can be done remotely over a network, so a server in a data center or an app on your phone talking to a cloud service isn’t exposed by this. The realistic targets are embedded and IoT devices that could plausibly fall into an attacker’s physical possession — think smart-card-like security tokens, not web servers.
That said, “patch the last step and call it done” clearly isn’t a complete defense, and we don’t think this earlier stage is the last word either — the same pattern likely shows up in other schemes built the same way. So alongside the attack, we designed and verified a lightweight fix: a version of that Booleanisation step that also keeps a running integrity check on itself, so that skipping even part of the computation is detected rather than silently defaulting to “safe.” It adds well under 0.01% overhead to decapsulation — essentially free — which is the kind of trade a real product can actually make.
For readers who want the real thing
Everything above is the simplified version. If you want the formal treatment — the precise fault model, the full decision-tree key-recovery procedure, the glitch parameters, the per-configuration results table, and the countermeasure’s correctness proof — the actual paper is on the IACR ePrint Archive:
This is joint work with de.ci.phe.red Lab members Anirudh Jaiswal (Project Associate) and Abhilash Kumar Das (Postdoc), both working as part of the National Quantum Mission.