krypteia — Side-Channel Analysis and Countermeasures

Status:

Draft

Version:

0.1

Scope:

Part I of the krypteia workspace — post-quantum cryptography (ML-KEM — countermeasures, ML-DSA — countermeasures, SLH-DSA — countermeasures). Part II (classical crypto in the arcana crate) is not covered here.

Document purpose

This document describes the physical and logical side-channel threat model that the quantica crate is designed to resist, and maps each threat to the corresponding countermeasure(s) implemented in the code together with:

• the published attack or countermeasure paper the construction is drawn from (Bibliography);

• a pointer to the exact source file(s) and function(s) implementing it (ML-KEM — countermeasures, ML-DSA — countermeasures, SLH-DSA — countermeasures);

• a qualitative estimate of the attack’s cost in equipment and effort when mounted against an unprotected implementation, so that the reader can judge the criticality of each countermeasure.

The intended audience is a cryptographic integrator or security reviewer deciding whether quantica fits their threat model, and contributors maintaining or extending the code.

Scope of the threat model

The analysis covers passive and active physical side-channels, and software-observable timing / memory-access side-channels:

• Simple / Differential / Correlation Power Analysis (SPA / DPA / CPA)

• Template attacks (supervised profiled attacks)

• Timing and cache-timing attacks (software attacker)

• Differential Fault Analysis (DFA) and Statistical Ineffective Fault Analysis (SIFA)

• Electromagnetic side-channels (SEMA / DEMA / CEMA — treated jointly with their power equivalents)

Purely cryptanalytic attacks on the underlying lattice / hash-based problems are out of scope — they are covered by the NIST security arguments for FIPS 203/204/205.

Document structure

Contents

• Threat model
  • Attacker model
  • Threat: Simple Power Analysis (SPA)
  • Threat: Differential / Correlation Power Analysis (DPA / CPA)
  • Threat: Template attacks
  • Threat: Software timing / cache-timing
  • Threat: Differential Fault Analysis (DFA) and SIFA
  • Threat: Electromagnetic side-channels (SEMA / DEMA / CEMA)
  • Summary table
• Shared side-channel primitives — silentops
  • Module layout
  • Constant-time primitives — silentops::ct
  • Architecture dispatch
  • ctgrind instrumentation — silentops::ct_grind
  • Statistical timing verification — silentops::verify
• ML-KEM — countermeasures
  • Coverage matrix
  • SPA / SEMA — NTT butterfly shuffling
  • DPA / DEMA / CPA — first-order masking of the KPKE secret
  • Timing / cache-timing — constant-time primitives everywhere
  • DFA — double computation + CT fault fallback
  • DFA on dk — H(ek) integrity check
  • Planned hardening
• ML-DSA — countermeasures
  • Coverage matrix
  • SPA / SEMA — Fisher-Yates shuffled NTT
  • DPA — first-order masking of secret polynomials
  • DPA on y — the sca-masked-y pipeline
  • Timing — constant-time rejection loop
  • Template attacks
  • Planned hardening
• SLH-DSA — countermeasures
  • Coverage matrix
  • Memory / stack-timing — iterative treehash + streaming signature
  • Timing — no secret-dependent branches in the public path
  • DFA / fault injection — current posture
  • Planned hardening
• Verification methodology
  • ctgrind (Valgrind memcheck) — control-flow CT
  • dudect (silentops::verify) — microarchitectural timing
  • Integration plan (Gitea workflows, upcoming)
  • release-asm branch counting — methodology and current state
• Bibliography

Audits

• Hermelink 2025/276 audit pass on ml_dsa::masked

Note

The companion document doc/infra/ctgrind.md is the operator-facing reference for running the Valgrind-based CT verifier. It is Markdown rather than rST and is not inlined here; link from Verification methodology when needed.

Change log

Date	Change
2026-04-21	Initial draft covering ML-KEM, ML-DSA, SLH-DSA; threat model; silentops primitives; ctgrind verification; current suppressions and Tier-4 hardening roadmap.