arcana — Side-Channel Analysis and Countermeasures

Status:

Draft (initial veille snapshot)

Version:

0.1

Scope:

Part II of the krypteia workspace — classical cryptography (AES — countermeasures, RSA — countermeasures, ECDSA / ECDH — countermeasures, EdDSA / Ed25519 — countermeasures, X25519 / X448 — countermeasures, HMAC / CMAC / KMAC / GMAC — countermeasures, Hash functions — countermeasures). Part I (post-quantum cryptography in the quantica crate) has its own annex under quantica/doc/sca/ with the same structural skeleton.

Document purpose

This document describes the physical and logical side-channel threat model that the arcana crate is designed to resist and the gaps where current code does not yet meet that target. It is both:

• a reference for an integrator or security reviewer deciding whether arcana fits their threat model, and

• a roadmap for the project’s hardening work towards a planned third-party evaluation / certification pass.

For each threat the document maps:

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

• the exact arcana source file(s) and function(s) that host (or will host) the relevant code;

• a qualitative estimate of the attacker effort against an unprotected baseline, so the reader can judge the criticality of each countermeasure;

• a status flag — implemented / partial / planned / deferred — that reflects the state of the code at the date of the changelog entry below.

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

Living document

The “planned” status entries — and indeed the whole tier-based hardening plan in the per-algorithm chapters — track the project’s security roadmap, not its current shipped state. They are expected to evolve as:

• new attacks are published (continuous veille — see the crypto-research skill workflow);

• countermeasures are implemented and graduate from planned to implemented (with verification artefacts under Verification methodology);

• deferred items move forward, are dropped, or are replaced by better techniques.

When a section is updated to reflect a new code state or a new veille run, append a row to the Change log table at the bottom of this page.

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) — Bellcore-class attacks on RSA-CRT, fault attacks on deterministic ECDSA / EdDSA

• Statistical Ineffective Fault Analysis (SIFA)

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

Purely cryptanalytic attacks on the underlying primitives (AES, SHA, RSA, ECC, …) are out of scope — they are covered by the underlying security arguments in FIPS 197, FIPS 180-4, FIPS 186-5, RFC 8017 and the underlying mathematical assumptions.

Evaluation scope

arcana is being prepared for a lab-class evaluation assuming a moderate-effort attacker in a 25-35 person-day evaluation window: passive observational attacks (timing, single- trace SPA, well-resourced DPA, template attacks with a clone) and single-fault active attacks (clock / voltage glitch, basic EMFI). Higher-order DPA, multi-fault, and chip-level inspection are not part of this level-1 attacker profile but are addressed in the tier-4 roadmap for future Common Criteria evaluations.

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), Bellcore, SIFA
  • Threat: Electromagnetic side-channels (SEMA / DEMA / CEMA)
  • Summary table
• Shared side-channel primitives — silentops
  • Constant-time selects
  • Volatile zeroization
  • Compiler shielding (black_box) for bit-mask CT
  • Statistical timing verification — silentops::verify
  • Architecture dispatch
• AES — countermeasures
  • Coverage matrix
  • SPA / cache-timing — Fixsliced AES (T1-A)
  • GMAC GF(2^128) multiplier (T2-H)
  • DPA and template attacks — masked AES (T2-G)
  • Outside the evaluation scope: AES-NI / VAES backend (T5)
  • Code path summary
• RSA — countermeasures
  • Coverage matrix
  • Bellcore single-fault attack — T1-C
  • SCA on bigint (T1-E)
  • DPA on Montgomery multiplication — message blinding (T2-I)
  • Padding-oracle hardening (T2-J)
  • Code path summary
  • Reading list
• ECDSA / ECDH — countermeasures
  • Coverage matrix
  • SPA / cache-timing — CT Montgomery ladder (implemented)
  • Minerva / LadderLeak — bit-length nonce leakage (T1-B)
  • DPA / CPA — Z-coordinate randomization (T2-A)
  • Scalar blinding (T2-B)
  • DFA on RFC 6979 deterministic signatures (T1-D)
  • Invalid-curve and small-subgroup defences (implemented)
  • Reading list
  • Code path summary
• EdDSA / Ed25519 — countermeasures
  • Coverage matrix
  • Background — Ed25519 signing flow
  • Single-fault → key recovery (T1-D)
  • SPA / DPA on the Edwards scalar multiplication (T1-F, T2-A)
  • Reading list
  • Code path summary
  • Ed448
• X25519 / X448 — countermeasures
  • Coverage matrix
  • Background — Montgomery ladder for X25519
  • Audit gaps (T1-G)
  • Z-randomization on (X : Z) (T2-A)
  • Scalar blinding (T2-B)
  • Reading list
  • Code path summary
• HMAC / CMAC / KMAC / GMAC — countermeasures
  • Coverage matrix
  • Carry-based DPA on HMAC-SHA-2 (T2-D)
  • CMAC / KMAC / GMAC
  • Code path summary
• Hash functions — countermeasures
  • Required CT properties
  • DPA / CDPA on the keyed-input path
  • Code path summary
• Verification methodology
  • Current state (2026-04-21)
  • ctgrind (Valgrind memcheck) — control-flow CT (T3-A)
  • dudect (statistical timing) — microarchitectural CT (T3-B)
  • Release-asm branch counting (current evidence)
  • Forward references
• Bibliography

Note

The companion document doc/infra/ctgrind.md is the operator-facing reference for running the Valgrind-based CT verifier — shared with the quantica side. 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. Captures the veille on classical-crypto SCA run on 2026-04-21 (LadderLeak, Minerva, Fixslicing AES, Carry-based DPA on HMAC-SHA-2, Bellcore RSA-CRT countermeasures, deterministic-signature fault attacks, Curve25519 ML-SCA, CT-tooling SOTA). Tier-based hardening plan defined for the evaluation. No countermeasure shipped yet on the arcana side beyond the always-on CT scalar multiplication (ECDSA / ECDH — countermeasures).