Constant-time implementation checks for PQC code

Short answer: A 2026 paper reports that code written to constant-time guidelines can still leak secrets through timing once it is compiled, because of CPU architecture limits as well as compiler optimization. A separate 2026 ePrint paper presents CT-KAT, a screening platform for constant-time risks in post-quantum (PQC) C implementations, and says a PASS from it is not proof of constant-time behavior. Both are research results.

Why Constant-Time Code Can Still Leak Secrets

The first paper says that cryptographic software adhering to recommendations for writing constant-time code, such as those in RFC 7748, may still leak secret data via naïve timing side channels. This occurs when a "secure" high-level language implementation is compiled down to assembly instructions. The vulnerability is not solely caused by aggressive compiler optimization. It also stems from inherent limitations of the target CPU architecture that the compiler must work around. Additionally, dangerous recommendations for instruction idioms found in architecture documentation contribute to the problem.

A specific instance involves the Xtensa IP core, which is affected by this issue. The authors identify a vulnerability where 64-bit addition on a 32-bit platform is implemented by the compiler using conditional jumps. This implementation opens a timing side channel. Consequently, even software developed according to good cryptographic practices and adhering to standard recommendations can be compromised. The problem persists because the compiler generates code that varies in execution time based on secret data, despite the source code's intent to remain constant-time.

Vulnerabilities in Xtensa-Based Hardware

The Xtensa architecture exhibits a particular vulnerability that has been studied and exploited. Key-recovery attacks were conducted against Xtensa-based ESP32 chips running ephemeral-static X25519 implementations. These implementations were found in the wolfSSL and CycloneCRYPTO libraries. Both libraries advertised their implementations as resistant against timing attacks, yet they used two unrelated implementation strategies. Despite these claims, the underlying architecture flaw allowed for successful attacks.

The authors report the attacks were four orders of magnitude more effective than a similar attack against a related vulnerability in the MSVC compiler known in the literature. The root cause was a compiler bug responsible for the vulnerability. The authors propose a resolution for the compiler bug. Furthermore, an optimized implementation of X25519 (Ed25519) and X448 (Ed448) field arithmetic for Xtensa was proposed. This optimized approach leverages a DSP extension to the core instruction set to mitigate the timing risks associated with the standard compilation path.

Automated Screening with CT-KAT

Following the standardization of major post-quantum cryptography algorithms, C implementations of ML-KEM, ML-DSA, and SLH-DSA have been rapidly deployed. However, known-answer tests (KATs) verify only functional correctness. They do not establish the absence of timing leakage caused by secret-dependent branches, memory accesses, or variable-latency instructions. To address this gap, the CT-KAT platform was developed for automated screening of constant-time risks in PQC C implementations.

CT-KAT is configured through a single YAML file. It validates the build and KAT execution and automatically generates harnesses for the functions under analysis. The platform performs several analyses within a unified pipeline. These include Valgrind/Memcheck-based structural checks, a ct-matrix over compiler and optimization-level combinations, and an assembly-level asm-scan. When configured, the pipeline also runs dudect-based timing tests. CT-KAT aggregates the results of these checks into a single verdict drawn from a nine-class taxonomy. CT-KAT does not treat a PASS result as proof of constant-time behavior. Instead, it applies a default-deny policy when assigning verdicts. It provides supporting evidence to guide manual triage, acknowledging that automated screening cannot fully certify security.

Application to PQC Algorithms

When applied to a PQClean-based PQC corpus, CT-KAT produced four main classifications. The baseline ML-KEM target was classified as robust. In contrast, the KyberSlash reproduction was flagged as a secret-dependent variable-latency risk, labeled varlat-secret-risk. The variable-time behavior of ML-DSA and SLH-DSA/SPHINCS+ was accepted under the label accepted-variable-time. Falcon-512 was retained for further analysis and labeled needs-analysis. The authors say these results show that CT-KAT provides a screening framework that integrates signals from various analysis techniques.

The labels show that the authors treat variable-time behavior differently depending on the verdict: ML-DSA and SLH-DSA/SPHINCS+ were accepted as variable-time, the KyberSlash reproduction was flagged as a risk, and Falcon-512 was kept for further analysis. The authors say the output is supporting evidence for manual triage, not a certification.

FAQ

Does passing a known-answer test prove constant-time behavior?

No. Known-answer tests verify only functional correctness. They do not establish the absence of timing leakage caused by secret-dependent branches, memory accesses, or variable-latency instructions. Additional screening is required to assess these risks.

Can compilers introduce timing vulnerabilities in constant-time code?

Yes. Compilers may introduce vulnerabilities through aggressive optimization or by working around inherent CPU architecture limitations. For example, 64-bit addition on 32-bit platforms might use conditional jumps, creating timing side channels even if the source code follows constant-time guidelines.

What is the role of the Xtensa DSP extension?

An optimized implementation of X25519 and X448 field arithmetic for Xtensa was proposed, leveraging a DSP extension to the core instruction set. The authors say it leverages the DSP extension to the core instruction set.

Does CT-KAT certify that an implementation is constant-time?

No. CT-KAT does not treat a PASS result as proof of constant-time behavior. It applies a default-deny policy when assigning verdicts and provides supporting evidence to guide manual triage. It is a screening tool, not a certification authority.

Why are variable-latency instructions a concern in PQC?

Variable-latency instructions can cause timing leakage if their execution depends on secret data. CT-KAT identifies secret-dependent variable-latency risks, such as in the KyberSlash reproduction, which were flagged as varlat-secret-risk. This distinguishes them from accepted variable-time behaviors that do not leak secrets.