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)

[ ] 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)

[ ] 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