Side-Channel Hazards in PQC
Post-quantum algorithms are mathematically resistant to quantum attacks, but their implementations introduce a fresh set of side-channel and timing pitfalls. Getting the math right is not enough — the code must be constant-time and leak-resistant.
Why PQC has new failure modes
Classical ECC and RSA implementations have decades of hardening behind them. Lattice, hash-, and code-based schemes bring operations that are unfamiliar and easy to get wrong: rejection sampling, modular reductions, Gaussian sampling, and re-encryption checks. A naive implementation can be functionally correct yet leak the secret key through timing, cache behaviour, or power consumption.
The main hazards
Secret-dependent branches and table lookups
If control flow or memory-access patterns depend on secret data, an attacker measuring timing or cache state can recover key bits. Polynomial arithmetic, NTT operations, and sampling loops must execute the same way regardless of secret values.
ML-DSA rejection sampling
ML-DSA signing uses rejection sampling: it repeats signing attempts until a candidate signature meets bound checks. Because ML-DSA signing involves rejection sampling, signing time can naturally vary. Implementations must ensure that the rejection conditions, bound checks, and handling of intermediate values do not leak secrets; in high side-channel-threat environments, dedicated constant-time/masked implementations and leakage assessment are required. See ML-DSA.
Falcon's floating-point Gaussian sampling
Falcon samples from a discrete Gaussian using floating-point arithmetic, which is notoriously hard to make constant-time: floating-point operations can take data-dependent time, and the sampler is the most sensitive part of the scheme. This is a major reason Falcon is harder to deploy safely than the integer-only lattice schemes. See Falcon.
KEM decapsulation and chosen-ciphertext timing
The most studied class of PQC side channels targets decapsulation. Decapsulation must follow the implicit-rejection logic of FIPS 203: the bad-ciphertext path also produces a pseudorandom shared secret, and a "decapsulation failure" must never be exposed through a return code, log, timing, or error branch. Branching on decapsulation failure creates a decryption-failure oracle that lets an attacker recover the secret key over many queries. Concrete examples include KyberSlash (a secret-dependent timing leak in a division during decoding) and broader decryption-failure-oracle attacks against earlier Kyber implementations. See ML-KEM.
Power and fault attacks
On embedded targets, differential power analysis and fault injection can extract key material even from algorithmically constant-time code. Smartcards, HSMs, and IoT devices need countermeasures beyond timing safety.
Mitigations
- Constant-time code. No secret-dependent branches, no secret-indexed table lookups, no early exits. Use constant-time comparison and conditional-move primitives.
- Implicit rejection, always. Implement the FO transform exactly as the standard specifies; never branch on a decapsulation mismatch.
- Avoid secret-dependent division. The KyberSlash class of bugs came from divisions whose timing depended on secret operands; replace them with constant-time multiply-and-shift.
- Masking. Split secrets into randomized shares so power/EM traces do not correlate with key bits — the standard defence against DPA on embedded devices.
- Prefer integer-only schemes where constant-time matters most. ML-DSA's integer arithmetic is easier to harden than Falcon's floating-point sampler.
- Formal verification. Tools that prove constant-time behaviour (e.g. timing-leak checkers and formally verified implementations) catch leaks that testing misses.
- Use vetted libraries. Do not hand-roll these primitives; rely on implementations that have been audited for side channels.
Related
Falcon →
Why its floating-point sampler is hard to protect.
ML-KEM →
Implicit rejection and the FO transform.
Testing & validation →
KATs catch correctness, not leakage.
Library matrix →
Choose audited, hardened implementations.
Standards & references
- Falcon project — the scheme whose floating-point Gaussian sampling is hardest to make constant-time.
- NIST PQC project — standards, rationale, and implementation guidance.
- Open Quantum Safe — vetted, side-channel-aware reference implementations.
- Resources — full standards register
PQC 中的侧信道风险
后量子算法在数学上能抵御量子攻击，但其实现引入了一整套新的侧信道与时序陷阱。仅把数学做对还不够，代码必须做到常数时间且抗泄漏。
为何 PQC 有新的失效模式
经典 ECC 与 RSA 实现背后有数十年的加固积累，而格、哈希与编码类方案带来了陌生且容易出错的运算——拒绝采样、模约简、高斯采样与重加密校验。一个功能正确的实现仍可能通过时序、缓存行为或功耗泄漏私钥。
主要风险
依赖秘密的分支与查表
若控制流或内存访问模式取决于秘密数据，攻击者测量时序或缓存状态即可恢复密钥比特。多项式运算、NTT 运算与采样循环必须无论秘密取值如何都以相同方式执行。
ML-DSA 的拒绝采样
ML-DSA 签名使用拒绝采样，反复尝试直到候选签名满足边界检查。ML-DSA 签名包含拒绝采样，签名耗时天然可能波动。实现应确保拒绝条件、边界检查和中间值处理不会泄漏秘密；在高侧信道威胁环境中，需要专门的常数时间/掩码实现与泄漏评估。参见 ML-DSA
Falcon 的浮点高斯采样
Falcon 使用浮点运算从离散高斯分布采样，这极难做到常数时间：浮点运算耗时可能依赖数据，而采样器又是方案中最敏感的部分。这也是 Falcon 比纯整数格方案更难安全部署的重要原因。参见 Falcon
KEM 解封装与选择密文时序攻击
研究最多的一类 PQC 侧信道针对解封装。解封装必须按 FIPS 203 的隐式拒绝逻辑执行：坏密文路径也产生伪随机共享秘密，且不能通过返回码、日志、时序或错误分支暴露‘解封装失败’。若依据解封装失败进行分支，就形成解密失败预言机，让攻击者通过多次查询恢复私钥。具体例子包括 KyberSlash（解码中某次除法存在依赖秘密的时序泄漏），以及针对早期 Kyber 实现更广义的解密失败预言机攻击。参见 ML-KEM
功耗与故障攻击
在嵌入式目标上，差分功耗分析与故障注入即便面对算法上常数时间的代码也能提取密钥材料。智能卡、HSM 与 IoT 设备需要超出时序安全之外的对策。
缓解措施
- 常数时间代码——不依赖秘密分支，不以秘密为下标查表，不提前退出，使用常数时间比较与条件移动原语。
- 始终隐式拒绝——严格按标准实现 FO 变换，绝不依据解封装不匹配进行分支。
- 避免依赖秘密的除法——KyberSlash 一类缺陷源于操作数为秘密时耗时不定的除法，应改为常数时间的乘法加移位。
- 掩码——把秘密拆成随机化份额，使功耗与电磁迹线不与密钥比特相关，是嵌入式抗 DPA 的标准手段。
- 在常数时间最关键处优先选纯整数方案——ML-DSA 的整数运算比 Falcon 的浮点采样器更易加固。
- 形式化验证——能证明常数时间性质的工具、时序泄漏检查器与经形式化验证的实现，可发现测试漏掉的泄漏。
- 使用经审计的库——不要自行实现这些原语，选用经过侧信道审计的实现。
相关
标准与参考
- Falcon 项目 — 其浮点高斯采样最难做到常数时间
- NIST PQC 项目 — 标准 设计依据与实现指南
- Open Quantum Safe — 经审计 注重侧信道的参考实现
- 资源链接 — 完整标准登记册