====== Crypto Module Checklist ======

**Version:** 2.1\\
**Scope:** Cryptographic primitives, protocols, key material, and crypto API design.

===== MUST (Merge Gate) =====

  * [ ] **Threat model** is documented (assets, attacker capabilities, trust boundaries, failure modes)
  * [ ] **Algorithm selection** is explicit and justified (no "home-grown crypto"; avoid obsolete primitives)
  * [ ] **Key material handling**: keys/seed material are never logged, never persisted unintentionally, stored in secure containers
  * [ ] **Randomness**: cryptographic randomness comes from approved CSPRNG; no ad-hoc RNG; no time-based seeds
  * [ ] **Nonce/IV rules** are enforced by design (unique where required; never reused; preferably generated internally)
  * [ ] **Constant-time comparisons** for MACs, hashes, and secret-dependent equality checks
  * [ ] **Side-channel posture** is stated (timing/cache/power expectations) and relevant operations have mitigations
  * [ ] **Input validation** is strict and rejects malformed encodings; length checks precede allocation
  * [ ] **Zeroization / lifecycle**: secret buffers are zeroized where feasible; key objects have deterministic disposal patterns
  * [ ] **Error behavior**: crypto failures return non-revealing errors (no oracle leaks); callers cannot distinguish secret-dependent failure branches
  * [ ] **Versioning & agility**: protocol/blob formats are versioned; parameters are encoded with ciphertext/signature where required
  * [ ] **Interoperability tests** exist (golden vectors or cross-implementation tests)
  * [ ] **Negative tests** exist (tamper, replay, truncation, wrong key, wrong nonce/iv, wrong context)

===== SHOULD (Strong Recommendations) =====

  * [ ] Prefer **AEAD** (e.g., ChaCha20-Poly1305 / AES-GCM) over "encrypt-then-MAC" unless there is a specific reason
  * [ ] Use **domain separation** (context strings, KDF labels) to avoid key/nonce reuse across contexts
  * [ ] For signatures/KEM: include **context binding** (who/what/why) to prevent substitution attacks
  * [ ] Use **structured encoding** (CBOR/ASN.1/Protobuf) with canonicalization rules; avoid ambiguous concatenation
  * [ ] Ensure **replay protection** where appropriate (sequence numbers, timestamps with skew policy, session tickets)
  * [ ] Avoid exposing overly powerful primitives directly; prefer **high-level APIs** that are difficult to misuse
  * [ ] Ensure **FIPS/standard alignment** where required (document compliance targets explicitly)

===== NICE (Quality) =====

  * [ ] Benchmark hot paths; document perf/security trade-offs
  * [ ] Provide migration guidance for algorithm upgrades (old -> new)
  * [ ] Provide a clear "misuse resistance" section in docs (common pitfalls and how the API prevents them)

----

//Version: 2.1 (Split)//\\
//Author: Wolfgang van der Stille//

Back to [[start|Security Checklists]] | [[..:start|Review Checklists]]

~~DISCUSSION:off~~