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

**Version:** 2.1\\
**Scope:** Kryptographische Primitives, Protokolle, Key Material und Crypto API Design.

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

  * [ ] **Threat Model** ist dokumentiert (Assets, Angreifer-Capabilities, Trust Boundaries, Failure Modes)
  * [ ] **Algorithm Selection** ist explizit und begründet (kein "home-grown crypto"; veraltete Primitives vermeiden)
  * [ ] **Key Material Handling**: Keys/Seed Material werden niemals geloggt, niemals unbeabsichtigt persistiert, in sicheren Containern gespeichert
  * [ ] **Randomness**: Cryptographic Randomness kommt von approved CSPRNG; kein ad-hoc RNG; keine time-based Seeds
  * [ ] **Nonce/IV Rules** werden by Design erzwungen (einzigartig wo erforderlich; niemals wiederverwendet; bevorzugt intern generiert)
  * [ ] **Constant-time Comparisons** für MACs, Hashes und secret-dependent Equality Checks
  * [ ] **Side-channel Posture** ist angegeben (Timing/Cache/Power Expectations) und relevante Operationen haben Mitigations
  * [ ] **Input Validation** ist strikt und lehnt malformed Encodings ab; Length Checks vor Allocation
  * [ ] **Zeroization / Lifecycle**: Secret Buffers werden zeroized wo machbar; Key Objects haben deterministische Disposal Patterns
  * [ ] **Error Behavior**: Crypto Failures geben non-revealing Errors zurück (no oracle leaks); Callers können secret-dependent Failure Branches nicht unterscheiden
  * [ ] **Versioning & Agility**: Protocol/Blob Formats sind versioniert; Parameter sind mit Ciphertext/Signature encodiert wo erforderlich
  * [ ] **Interoperability Tests** existieren (Golden Vectors oder Cross-Implementation Tests)
  * [ ] **Negative Tests** existieren (Tamper, Replay, Truncation, Wrong Key, Wrong Nonce/IV, Wrong Context)

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

  * [ ] Bevorzuge **AEAD** (z.B. ChaCha20-Poly1305 / AES-GCM) über "encrypt-then-MAC" außer es gibt spezifischen Grund
  * [ ] Verwende **Domain Separation** (Context Strings, KDF Labels) um Key/Nonce Reuse über Contexts zu vermeiden
  * [ ] Für Signatures/KEM: **Context Binding** einschließen (who/what/why) um Substitution Attacks zu verhindern
  * [ ] Verwende **Structured Encoding** (CBOR/ASN.1/Protobuf) mit Canonicalization Rules; ambigious Concatenation vermeiden
  * [ ] Sicherstellen **Replay Protection** wo passend (Sequence Numbers, Timestamps mit Skew Policy, Session Tickets)
  * [ ] Overly powerful Primitives nicht direkt exponieren; bevorzuge **High-level APIs** die schwer zu misbrauchen sind
  * [ ] Sicherstellen **FIPS/Standard Alignment** wo erforderlich (Compliance Targets explizit dokumentieren)

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

  * [ ] Hot Paths benchmarken; Perf/Security Trade-offs dokumentieren
  * [ ] Migration Guidance für Algorithm Upgrades bereitstellen (old -> new)
  * [ ] Klare "Misuse Resistance" Sektion in Docs (common pitfalls und wie API sie verhindert)

----

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

Zurück zu [[.:start|Sicherheit Checklists]] | [[..:start|Review Checklists]]

~~DISCUSSION:off~~