Implementation Risk In Post-Quantum Cryptography: KyberSlash And FIPS 140-3

Choosing a standardised post-quantum algorithm is only part of the job. The algorithm has to be implemented in code, that code has to run on real hardware, and the hardware leaks information through timing, power use and electromagnetic signals. The NSA observes that more security products fail through implementation or configuration errors than through weaknesses in their underlying algorithms.¹

Post-quantum code is newer than RSA or elliptic curve code and has had less time in the field. Germany’s BSI says as much: its guidance describes the quantum-safe methods as comparatively new and less studied, especially in terms of implementation security.² This article looks at a concrete example, the specific difficulties with FN-DSA, and how the US and Canadian validation programmes help buyers tell tested implementations from untested ones.

KyberSlash: A Sound Algorithm, Leaky Code

KyberSlash is the name given to a set of timing flaws in Kyber software, the algorithm that became ML-KEM. Several libraries, including the official reference code, contained a line that divided a secret value by a public constant. On many processors, the time a division takes depends on the numbers involved, so the running time leaked information about the secret.³

The researchers who documented the flaws, a team including Daniel J. Bernstein, showed that this leak was exploitable. In their paper, published in the IACR Transactions on Cryptographic Hardware and Embedded Systems in 2025, one variant recovered Kyber secret keys within minutes and another within hours, in demonstrations on a Raspberry Pi 2 and an Arm Cortex-M4 microcontroller.⁴ The project’s tracking page lists which libraries were affected and how they were fixed.³

The lesson is not that ML-KEM is weak. The mathematics was untouched. The lesson is that constant-time coding, where running time does not depend on secret data, has to be checked rather than assumed, including in reference code that many projects copy.

Defensive Requirements In The Standards

The standards themselves include safeguards. FIPS 203 requires input checking before ML-KEM uses an encapsulation key or a decapsulation key, so that malformed keys are rejected rather than processed.⁵ Implementations that skip these checks are not compliant, however fast they are.

Standards also get corrected. In November 2025 NIST added a note to the FIPS 203 page saying it had identified an issue to be fixed in a future update, with details in a published errata list.⁶ Teams that maintain their own implementations should watch these pages rather than treat a standard as frozen.

Why FN-DSA Is Harder

FN-DSA, the coming FIPS 206 standard based on Falcon, has the smallest signatures and public keys of NIST’s lattice signatures. Falcon as submitted, however, uses floating-point arithmetic in key generation and signing. In 2025 NIST said this creates challenges for both validation and side-channel protection, and that correct signature distribution is essential to avoid leaking the private key. Its plan at that point included allowing only randomised signing and requiring signing implementations to match test vectors exactly.⁷

In September 2026 NIST went further. Its FIPS 206 team proposed that the standard should specify fixed-point arithmetic for both key generation and signing, define one signing procedure in enough detail that implementations can be validated by matching known answer tests exactly, and leave other signing techniques for possible later guidance. It asked the community whether this was a good plan, so the details may still change.⁸

The NSA has drawn its own conclusion. It prefers ML-DSA for national security systems because FN-DSA seems more susceptible to implementation errors, and it does not plan to add FN-DSA to CNSA 2.0.¹

How Validation Fits Together

In the US and Canada, two linked programmes test cryptographic implementations. The Cryptographic Algorithm Validation Program (CAVP) checks that an implementation of an approved algorithm produces correct results, using automated test vectors. The Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security, validates a whole cryptographic module against FIPS 140-3, the standard for module security.⁹¹⁰

Algorithm validation is a prerequisite for module validation but is not enough on its own. A module must also meet the wider FIPS 140 requirements before its algorithms can be listed as approved functions.⁹ For US federal agencies the stakes are high: CMVP guidance states that unvalidated cryptography is treated as providing no protection to the data.¹⁰

Validation does not prove an implementation is free of side channels. CAVP testing compares an implementation’s outputs with expected results; it does not measure how long the code takes or how much power it draws. Treat a certificate as strong evidence of correctness and process, and still ask about constant-time design.

Timing also matters for buyers. CMVP has accepted FIPS 140-3 submissions since September 2020, and its page states that FIPS 140-2 validations were due to move to historical status on 21 September 2026.¹⁰ Check the CMVP search for the current certificate of any module you rely on, and confirm which post-quantum algorithms it actually covers.