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

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

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

• [ ] 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 Sicherheit Checklists | Review Checklists