Post-quantum cryptography is the new generation of encryption designed to stay secure even against future quantum computers. We discovered that a popular compiler tool has been silently undermining it since 2022 — on every major operating system, across every version — and that a single configuration change fixes the problem entirely.
No cryptography background needed to understand this
Encryption only works if an attacker cannot figure out your secret key by watching how long operations take. If the code runs slightly faster or slower depending on parts of the key, a patient attacker can measure those differences and reconstruct the key — no supercomputer needed.
The developers of HQC — one of the three post-quantum encryption algorithms chosen by the US government (NIST) — wrote their code carefully to avoid timing differences. It passed every security check. But a compiler called Clang (software that translates human-written code into a program a computer can actually run) quietly "optimised" it in a way that reintroduced exactly the timing variation the developers had worked to remove.
Every version of Clang released since June 2022 — including the current version — has this behaviour. On Linux. On Windows. At every standard optimisation setting. Anyone who compiled HQC with Clang during this time has a vulnerable binary, without knowing it.
Adding a single flag to the build command completely eliminates the vulnerability. Surprisingly, it also makes the encryption code run more than 3 times faster, because the "optimisation" Clang was applying was actually slowing things down by forcing the processor to repeatedly guess wrong.
Inside Clang there is a component called x86-cmov-converter — an internal optimiser that looks at certain safe, branchless instructions and decides "a conditional jump here would be faster." For normal code it is sometimes right. For secret cryptographic data it is always wrong, because the processor cannot predict which way the jump will go (the outcome depends on a secret it has never seen), so it guesses wrong roughly half the time. Each wrong guess wastes ~15 processor cycles. Across one encryption operation that adds up to millions of wasted cycles — making the vulnerable binary over 3× slower than the fixed one. Disabling this component with a single build flag restores both security and performance in one move.
Disabling x86-cmov-converter eliminates the vulnerability and makes the code 3.07× faster than unpatched Clang and 2× faster than GCC — because the "optimisation" was causing the processor to mispredict branches on secret data, wasting millions of cycles per operation.
x86-cmov-converter in the LLVM x86 backend.-mllvm -x86-cmov-converter=false) fixes all 20 tested configurations with no source code changes.This flag works with every Clang version from 14 onwards, requires no source code changes, and is safe to add unconditionally. It is a no-op with GCC.
Coordinated disclosure filed with the open-source maintainers: PQClean #608 · liboqs #2402