.. krypteia Side-Channel Analysis and Countermeasures — arcana side
   master file.

###################################################################
arcana — Side-Channel Analysis and Countermeasures
###################################################################

:Status:  Draft (initial veille snapshot)
:Version: |release|
:Scope:   Part II of the krypteia workspace — classical cryptography
          (:doc:`countermeasures/aes`, :doc:`countermeasures/rsa`,
          :doc:`countermeasures/ecdsa_ecdh`,
          :doc:`countermeasures/eddsa`,
          :doc:`countermeasures/x25519_x448`,
          :doc:`countermeasures/hmac`,
          :doc:`countermeasures/hashes`).
          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 (:doc:`biblio`);
* 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
  :doc:`verification`);
* 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 :ref:`changelog` 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
==================

.. toctree::
   :maxdepth: 2
   :caption: Contents

   threat_model
   primitives
   countermeasures/aes
   countermeasures/rsa
   countermeasures/ecdsa_ecdh
   countermeasures/eddsa
   countermeasures/x25519_x448
   countermeasures/hmac
   countermeasures/hashes
   verification
   biblio

.. note::

   The companion document :file:`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 :doc:`verification`
   when needed.

.. _changelog:

Change log
==========

.. list-table::
   :header-rows: 1
   :widths: 20 80

   * - 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
       (:doc:`countermeasures/ecdsa_ecdh`).