Is ML-KEM vulnerable to side-channel attacks?

An ML-KEM side-channel attack is an attempt to pull secret key material out of a device running ML-KEM, the post-quantum key encapsulation mechanism standardised in FIPS 203. It works by watching physical or timing side effects of the computation rather than by breaking the mathematics. The scheme itself stays sound. The weak point is the implementation, and that matters most for encryption gateways installed at remote, lightly supervised OT sites.

This article explains where these leaks come from, what the KyberSlash case taught implementers, which countermeasures work on edge hardware, why key reuse matters for VPN and TLS gateways, and how operators of critical infrastructure can judge the physical risk at each site.

Is ML-KEM vulnerable to side-channel attacks?

ML-KEM as a mathematical scheme is not known to be weak, but any implementation of it can leak secrets through timing, power consumption or electromagnetic emissions if it is not built with countermeasures. NIST says so explicitly in its own KEM guidance.

ML-KEM is the name given to the algorithm in this standard derived from CRYSTALS-KYBER, and its security in theory rests on lattice problems. In practice NIST treats implementation security as a separate requirement. NIST SP 800-227 lists the conditions a KEM deployment has to meet and stresses that each of these three conditions is essential for security. For example, a KEM that is theoretically secure (i.e., satisfies condition 1) but is implemented without side-channel countermeasures does not meet that bar.

Lattice schemes are also harder to protect than RSA or elliptic curves. Speaking at a NIST seminar in April 2023, Markku-Juhani O. Saarinen summarised the consensus view: “Masking and other attack mitigation techniques for PQC algorithms are technically more complex than for older cryptography.” The reason he gives is that the algorithms are not homogenous like RSA or ECC but contain a number of dissimilar steps. One may have to design dozen different gadgets for one algorithm.

What was the KyberSlash timing vulnerability and which implementations were affected?

KyberSlash was a class of timing leaks, disclosed around the turn of 2024, in which a division operation took a different number of cycles depending on secret data. It affected the Kyber reference code and many libraries derived from it.

The IETF lists KyberSlash as a standard example of an attack that exploits implementation issues, such as [KYBERSLASH], which exploits timing variations. The technical root cause was mundane. When compiling the reference Kyber implementation released before the discovery of Kyberslash for minimal code size (-0s), an operand-dependent division operation is used on certain platforms. As one of these operands is a coefficient of the secret key used for decryption, this division operation poses a side channel that can be used to reconstruct the private key entirely.

• Size of the leak: in an independent 2025 reproduction on an affected ARM processor, the two inputs produced a slow division, and one expected to yield a fast division resulting in a difference of 20 cycles (arXiv 2504.19821, April 2025).

Twenty cycles looks negligible, but with statistics across many measurements it becomes a usable signal. The full analysis was published by D. J. Bernstein and co-authors as “KyberSlash: Exploiting secret-dependent division timings in Kyber implementations”, 30 June 2024.

The lesson for OT goes beyond patching one library. Code that was “constant-time” in C was not constant-time after a particular compiler and CPU got hold of it. Embedded gateways and industrial devices often ship firmware built with size-optimising flags for small processors, which is exactly the setting where the leak showed up. Timing leaks also have a property that matters for remote sites: unlike other side-channel attacks (e.g., electromagnetic attacks and power consumption attacks), restricting physical access to the target device is not sufficient to prevent them.

How do power and electromagnetic attacks target ML-KEM keys on embedded devices?

Power and electromagnetic (EM) analysis tie tiny variations in a device’s current draw or radiated field to the secret values being processed. Unlike timing leaks, they need physical proximity, and they are most relevant for small embedded processors.

Inside ML-KEM decapsulation the secret key is multiplied with ciphertext data in the Number Theoretic Transform (NTT) domain, the message is decoded, and the result is re-encrypted and compared. Each step handles secret-dependent values. Hardware research describes how secrets appear in Number Theoretic Transform (NTT) coefficient arrays, with dominant operations such as integer multiplication, XOR, and shift, and every one of those operations draws slightly different power depending on its operands.

The academic literature covers several families of technique: simple power analysis (SPA), differential power analysis, correlation power analysis, and machine learning. Published work has also looked at single-trace leakage in the message encoding step of lattice KEMs, for example Sim et al., Single-Trace Attacks on Message Encoding in Lattice-Based KEMs. IEEE Access, 2020.

Two factors set the real-world risk: how many measurements an adversary can collect against the same private key, and how noisy the platform is. A multi-core x86 system running many processes produces far noisier measurements than a single-purpose microcontroller, though that noise is no substitute for proper countermeasures.

Which countermeasures protect ML-KEM on edge hardware?

The basics are constant-time code verified at binary level, masking of secret values in decapsulation, a protected Fujisaki-Okamoto re-encryption check, and short-lived keys. How far to go beyond constant-time code depends on how easy it is to get physical access to the device.

Constant-time code, verified after compilation

Constant-time means no branches, memory lookups or variable-latency instructions (such as division) that depend on secrets. Since KyberSlash, careful implementers check the compiled binary on the target architecture rather than relying on the source code. That check has to cover subtle effects too: research presented at NIST describes how the hamming weight of used operands affects the temperature of the CPU, which can cause the CPU to slow down due to dynamic CPU frequency scaling to avoid overheating. This slowdown can be measured by an attacker, who then leaks the Hamming weight of the involved secrets.

Masking and shuffling

Masking splits every secret into random shares so that no single intermediate value correlates with the key. In ML-KEM this is awkward: the s and e distributions are non-uniform. Kyber and Dilithium require a lot of mixing (mod q) arithmetic masking with Boolean masking, and the SHA-3 functions inside the scheme need their own protected implementation. Shuffling randomises the order of operations, which makes single-trace analysis harder.

Protecting the Fujisaki-Okamoto transform

ML-KEM gets its chosen-ciphertext security from the Fujisaki-Okamoto transform: decapsulation re-encrypts the decrypted message and compares the result with the received ciphertext. The wrapper is known as the “Fujisaki-Okamoto Transform.” It is essential to protect against Chosen Ciphertext Attacks (CCA) if the secret key is fixed (not ephemeral). The comparison and the selection between the real and the rejection key must themselves run in constant time. The authors of the IETF CFRG ML-KEM Security Considerations draft warn that skipping this check is dangerous because “a maliciously generated ciphertext could induce decapsulation failures that can allow an attacker to deduce the private key”.

What protection costs

Masking has a measurable price in performance, which matters on edge devices with limited compute:

• A first-order masked software decapsulation on a common 32-bit microcontroller core requires only 4,077,819 cycles which already includes randomness generation from the internal RNG (Heinz et al., NIST Third PQC Standardization Conference, 2021).
• The authors practically verify our implementation by using the t-test methodology with 100,000 traces (Heinz et al., 2021).
• In hardware, the masked implementation requires 2.5× more LUTs and 6.5× more clock cycles for decapsulation (NIST Fourth PQC Standardization Conference, 2022).

Why is ML-KEM key reuse risky for VPN and TLS gateways?

Reusing an ML-KEM decapsulation key across many sessions turns a single-use secret into a long-lived target. An adversary then gets many measurements against the same key, and forward secrecy is weakened. NIST SP 800-227 now draws a sharp line between ephemeral and static keys.

Mathematically, reuse is not a flaw: ML-KEM is IND-CCA2 secure; that is, it remains secure even if an adversary is able to submit arbitrary ciphertexts against a fixed public key and observe the resulting shared key. The trouble is physical. Differential power and EM techniques depend on repetition, and a gateway that caches one key pair for hours, to save the cost of key generation, gives an adversary exactly that. Gorjan Alagić of NIST summed up the new SP 800-227 guidance as “”ephemeral” = use once, then destroy”, adding that anything else counts as static, which comes with baggage: must prove it belongs to you!

The IETF draft also points to a subtler risk: as decryption failures can leak information about the secret decapsulation key, it is important that Alice keeps a secure copy of the public key as part of her secret key. It also asks for key hygiene, recommending that a party zeroize her private key when she will have no further need of it. That draft is advisory: it is not endorsed by the IETF and has no formal standing in the IETF standards process.

For gateways, the practical rule is a fresh key pair per handshake, frequent rekeying, and erasing secrets right after use. Quantum Network’s Quantum Gateway, for example, combines a classical and an ML-KEM key agreement into one session key and renews both handshakes every two minutes. That keeps each key’s exposure window short.

How should OT operators assess the physical attack risk of encryption gateways at remote sites?

Assess each site on three factors: who can get physically close to the gateway and for how long, how many operations an adversary could observe against one key, and what the hardware and update model looks like. Then choose controls to match, instead of applying one policy to every location.

Map physical exposure per site

A gateway in a guarded control room is a different risk from one in a pole-mounted cabinet at an unmanned pumping station. For each site, note how long someone could work undisturbed, whether the enclosure has tamper switches tied to the SCADA alarm system, and whether contractors have keys. Power and EM techniques usually need extended, undisturbed access. Short, alarmed access windows lower that risk considerably.

Check the key lifecycle, not just the algorithm

Ask suppliers whether ML-KEM keys are ephemeral, how often sessions rekey, and whether secrets are zeroised after use. A gateway that rekeys every few minutes with fresh key pairs limits how many traces anyone can collect against one key.

Ask for evidence on the implementation

Ask which ML-KEM code base is used, whether it was checked after KyberSlash, whether constant-time behaviour was verified on the shipped binary and CPU, and whether masking applies. General-purpose x86 hardware and small microcontrollers carry different profiles, so the answer should name the platform.

Plan for updates over a long lifetime

OT assets stay in service for decades, and implementation flaws like KyberSlash are found after deployment. Find out how cryptographic fixes reach air-gapped or remote sites and what happens when support ends. With QPN, for instance, automatic algorithm and software updates require an active subscription. Without one the gateway keeps running but receives no further security updates, so this belongs in the lifecycle plan from day one.

Keep the threat model in proportion

An encryption gateway protects data in transit. It does not protect the PLCs and HMIs behind it, and physical access that lets someone probe a gateway may also give access to the field devices themselves. Weigh side-channel risk against that wider picture. In most remote OT sites, verified constant-time code, ephemeral keys and tamper-alarmed enclosures address the realistic threat. Masked implementations deserve priority where adversaries could plausibly get undisturbed physical access for long periods.