up:: Classical Cryptography MOC

Side-Channel and Fault Attacks on PQC

Migrating to post-quantum cryptography closes the math exposure to a quantum computer and opens a fresh physical one that has to be engineered against separately. ML-KEM and ML-DSA are safe against Shor’s algorithm on paper, and a careless implementation of either can still hand over its key through a side channel, a timing wobble, a power fluctuation, or an induced fault. The 2024 KyberSlash attack proved this concretely by pulling secrets out of ML-KEM implementations through a single division instruction whose timing leaked. The lattice arithmetic underneath the standards is harder to make leak-free than classical crypto was, which is why masking and hiding countermeasures for ML-KEM and ML-DSA are an active engineering discipline rather than a solved problem.

The short version:

• Quantum-safe math does not mean leak-safe code. Side channels and fault injection attack the running device, so a post-quantum scheme can be broken in implementation while its math stays perfectly sound.
• KyberSlash is the worked example. Disclosed in 2024, it recovered ML-KEM secret keys from a division-by-the-modulus operation whose execution time depended on secret data on some platforms.
• Constant-time lattice code is genuinely hard. Lattice schemes are full of secret-dependent steps, polynomial arithmetic, rejection sampling, the decapsulation comparison, and floating-point sampling in FN-DSA, that resist being made timing-invariant.
• Masking is the leading software defense. Splitting every secret value into random shares breaks the correlation a power or electromagnetic attack needs, and it is the primary countermeasure researchers are building for ML-KEM and ML-DSA.
• Fault attacks are the active cousin. Deliberately glitching a device during signing or decapsulation can force it to leak or misbehave, so high-assurance PQC needs fault detection on top of side-channel defense.

Picture a brand-new safe with a lock no thief can pick, installed by a contractor in a rush. The lock is flawless, and the contractor mounted it on a hollow door that rattles a slightly different way depending on which number the dial is passing. A patient listener at the door never touches the unpickable lock; they read the rattles. Swapping to a quantum-safe algorithm is installing the better lock. It does nothing about the hollow door, which is the implementation, and closing the physical leaks in that door is a separate job that the post-quantum transition makes newly urgent because the lattice locks rattle in unfamiliar ways.

Do post-quantum algorithms have side-channel risks?

Yes, and treating them as automatically safe because they are new and quantum-resistant is one of the more dangerous assumptions in a migration. Quantum resistance is a property of the mathematics: it says a quantum computer running Shor’s algorithm cannot solve the underlying problem. It says nothing about whether the chip running the algorithm leaks the key through its timing, its power draw, or its electromagnetic emissions. A side-channel attack targets exactly those physical byproducts, so an ML-KEM or ML-DSA implementation without proper countermeasures can surrender its secret key to a power or timing attack while its math remains untouched.

Source: NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, Section 3.3, August 13, 2024, csrc.nist.gov.

NIST took this seriously enough to break with historical precedent. For AES and earlier standards, most side-channel analysis happened in the years after the algorithm shipped. For the post-quantum process, NIST asked the community to study side-channel resistance during standardization, and researchers produced a large body of work on the lattice candidates in particular. The concern is written into the standard itself: FIPS 203 states plainly that conforming to the standard does not by itself guarantee a secure implementation and includes a rule requiring implementers to destroy intermediate values, because “data used in intermediate computation steps of KEM algorithms could be used by an adversary to compromise security.” That is a side-channel requirement sitting inside a math standard.

What is the KyberSlash attack?

KyberSlash is a timing side-channel attack, disclosed in 2024, that recovered secret keys from reference implementations of ML-KEM (Kyber) by exploiting a division instruction whose running time depended on the secret it was operating on. The vulnerable code divided a secret-derived numerator by the public modulus, and on several platforms the number of processor cycles a division takes varies with its inputs. That timing variation, measured across many operations, leaked enough about the secret numerator to reconstruct the private key. The flaw lived in widely used implementations of a NIST standard, which is what made it a wake-up call rather than an academic curiosity.

Source: D. J. Bernstein et al., “KyberSlash: division timings depending on secrets in Kyber software,” 2024, kyberslash.cr.yp.to.

The lesson of KyberSlash is precise and uncomfortable. The leak was not in the design of ML-KEM, which is sound, and not in some exotic laboratory measurement. It was one arithmetic operation, a division by a constant, that a developer would reasonably assume runs in fixed time, silently taking variable time on real hardware. This is the exact texture of the constant-time problem: the danger hides in ordinary-looking code, at the level of a single instruction, in a place no algorithm-level review would flag. It is also a reminder that “it uses the NIST-standard algorithm” says nothing about whether a given build is side-channel safe, which is why implementation quality has to be verified separately from the choice of algorithm.

Why is constant-time lattice code so hard to get right?

Constant-time code (code whose execution time carries no dependence on secret data) is the baseline defense against timing and cache attacks, and lattice schemes are unusually full of the secret-dependent operations that break it. Classical elliptic-curve and RSA code had a relatively small set of well-known danger spots. Lattice cryptography has more moving parts, and several of them are naturally data-dependent in ways that take real effort to flatten:

1. Polynomial arithmetic and modular reduction. ML-KEM and ML-DSA operate on polynomials with hundreds of coefficients, reduced modulo a prime, and the naive ways to write that reduction (including division by the modulus, the exact KyberSlash pitfall) can take secret-dependent time.
2. The decapsulation comparison. The Fujisaki-Okamoto re-encryption check inside ML-KEM compares a recomputed ciphertext against the received one, and a comparison that exits early on the first mismatch leaks where they differed. It has to run to completion every time.
3. Rejection sampling. ML-DSA signing rejects and retries when an intermediate value falls out of bounds, and the number of retries and which values were rejected can depend on the secret, creating a timing and behavioral channel.
4. Floating-point Gaussian sampling. FN-DSA (FALCON) draws its randomness from a Gaussian distribution using floating-point arithmetic that is notoriously hard to make constant-time, which NIST flagged as a practical implementation hazard, especially on constrained devices.

Source: NIST IR 8413-upd1, “Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process,” 2022, csrc.nist.gov.

The through-line is that lattice cryptography’s efficiency comes from arithmetic that is data-rich and full of branch points, and every branch point that touches a secret is a potential leak. Making it constant-time means rewriting each of these steps to run the same instructions in the same order regardless of the secret, which is painstaking, easy to get subtly wrong, and (as KyberSlash showed) easy to reintroduce with one innocent-looking line.

How do masking and hiding countermeasures defend PQC?

The defenses split into removing the secret-to-measurement correlation (masking) and burying it in noise (hiding), layered on top of a constant-time baseline, and masking is the leading software countermeasure the research community is building for the lattice standards. Constant-time coding closes timing and cache leaks, and it does nothing for the power and electromagnetic channels, where the chip’s energy use still tracks the secret data it processes. That is the gap masking and hiding fill.

1. Masking splits every secret intermediate value into several random shares that are computed on separately and only recombined at the end, so any single measured value is randomized and uncorrelated with the real secret. Higher-order masking uses more shares to resist stronger statistical attacks, at a steep performance cost, and it is the primary defense researchers are developing for ML-KEM and ML-DSA. Masking lattice schemes is harder than masking AES, because their mix of arithmetic and Boolean operations forces expensive conversions between share types.
2. Hiding adds noise or shuffles the order of independent operations so an attacker cannot cleanly line up traces to average away the noise. It raises the number of measurements an attack needs rather than closing the leak, so it is a complement to masking, not a replacement.
3. A constant-time foundation underneath both, because masking a design that still has a secret-dependent branch leaves the timing channel wide open.

Source: J. W. Bos, M. Gourjon, J. Renes, T. Schneider, C. van Vredendaal, “Masking Kyber: First- and Higher-Order Implementations,” IACR Transactions on Cryptographic Hardware and Embedded Systems (TCHES) 2021(4), tches.iacr.org / IACR ePrint 2021/483.

The honest tradeoff is the same one that has always governed side-channel defense: every countermeasure costs performance, memory, or design complexity, and a fully masked, higher-order lattice implementation can run several times slower than an unprotected one. That cost is the structural reason unprotected builds keep shipping and keep getting broken, and it is why side-channel protection is a deliberate requirement to specify and verify, not something you get for free by picking a NIST algorithm.

Where do fault attacks fit in?

Fault attacks are the active counterpart to passive side-channel analysis, and they matter for PQC because deliberately corrupting a computation during signing or decapsulation can force a device to leak a secret or produce an exploitable wrong answer. Where a side-channel attack only observes the device, a fault attack reaches in and disturbs it, using a voltage glitch, a clock glitch, an electromagnetic pulse, or a laser to flip a bit or skip an instruction at a chosen moment. The classic target is a signature: if an attacker can induce a fault during ML-DSA or FN-DSA signing and collect both a correct and a faulted signature of related data, the pair can sometimes reveal the private key.

The specific fault surface in lattice schemes mirrors their side-channel surface, since the same sensitive steps (the rejection-sampling loop in ML-DSA, the FO re-encryption check in ML-KEM, the Gaussian sampler in FN-DSA) are the natural places to inject a disturbance. Skipping the re-encryption check with a well-timed glitch, for instance, would defeat the very mechanism that makes decapsulation safe against chosen-ciphertext attacks.

Defending against faults means adding detection: recomputing critical steps and comparing, verifying a freshly produced signature before releasing it, and hardware-level glitch sensors on high-assurance devices. For anything an attacker can hold and power (a smart card, a payment chip, a hardware token) fault resistance belongs in the requirement set alongside side-channel resistance, because the two attack classes are routinely combined.

Common misconceptions

• “Post-quantum algorithms are safe from physical attacks because they are new and quantum-resistant.” Quantum resistance is a property of the math. ML-KEM and ML-DSA have secret-dependent operations that have been broken in unprotected implementations, which is why NIST studied their side-channel resistance and FIPS 203 mandates destroying intermediate values.
• “KyberSlash means ML-KEM is broken.” The ML-KEM design is sound. KyberSlash was an implementation flaw in specific software, a division whose timing leaked, and it was fixed by rewriting that step to run in constant time. It shows that implementation quality must be verified separately from the algorithm choice.
• “Constant-time code fully protects a post-quantum implementation.” Constant-time coding closes timing and cache leaks and leaves the power and electromagnetic channels open, where the chip’s energy use still tracks the secret. Full protection layers masking and hiding on top of a constant-time base.
• “Masking is a solved, drop-in fix.” Masking lattice schemes is harder than masking AES because of their mix of arithmetic and Boolean operations, it carries a steep performance cost, and it is still an active research area, which is why building masked ML-KEM and ML-DSA remains difficult engineering.
• “Fault attacks are the same thing as side channels.” Side-channel analysis passively observes a device; fault injection actively disturbs it to force a leak or an exploitable error. They are cousins in the field of implementation attacks and are often used together, so high-assurance PQC needs defenses against both.

Questions people ask

Does migrating to ML-KEM or ML-DSA close my side-channel exposure? No. It closes the quantum-math exposure and leaves the physical one, which is a separate engineering problem. An unprotected post-quantum implementation can leak its key through timing, power, or electromagnetic channels exactly as an unprotected classical one can, so the implementation has to be hardened and verified on its own.

What was KyberSlash? A 2024 timing attack that recovered ML-KEM secret keys from reference implementations by exploiting a division by the modulus whose execution time depended on secret data on some platforms. It was an implementation flaw, fixed by making that division constant-time, and a clear demonstration that using a standard algorithm does not guarantee a safe build.

Why is constant-time code harder for lattice crypto than for RSA or ECC? Lattice schemes have more secret-dependent operations: polynomial arithmetic and modular reduction, the FO decapsulation comparison, rejection sampling in ML-DSA, and floating-point Gaussian sampling in FN-DSA. Each is a place where secret-dependent timing can creep in, and flattening all of them is painstaking and easy to get subtly wrong.

What is masking and why does it come up so much with PQC? Masking splits each secret value into random shares processed separately, so no single measured value correlates with the real secret. It is the leading software defense against power and electromagnetic attacks, and it comes up constantly for lattice schemes because their arithmetic has many secret-dependent steps and masking them is harder and slower than masking AES.

Are fault attacks a real concern for post-quantum signatures? Yes, for devices an attacker can physically reach. Inducing a fault during ML-DSA or FN-DSA signing can, with the right pair of signatures, expose the private key, and skipping the ML-KEM re-encryption check with a glitch would defeat its chosen-ciphertext protection. High-assurance implementations add fault detection alongside side-channel countermeasures.

How do I tell whether a post-quantum product is side-channel resistant? Not from the algorithm name, since two products using the same standard can differ enormously in implementation quality. Meaningful assurance comes from independent evaluation and certification of the physical implementation, such as testing under FIPS 140-3 and related lab programs, rather than from the datasheet claiming a NIST algorithm.

---

Everything here is the map, given freely. When your team needs to know whether the implementations behind its post-quantum migration actually hold up against attacks like these, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.