Versione: 2.1
Ambito: Primitive crittografiche, protocolli, materiale chiavi e design API Crypto.

• [ ] Threat Model documentato (Asset, capacità attaccante, confini fiducia, modalità fallimento)
• [ ] Selezione algoritmo esplicita e giustificata (niente „crypto fatto in casa“; evitare primitive obsolete)
• [ ] Gestione materiale chiavi: Chiavi/materiale seed mai registrati, mai persistiti involontariamente, conservati in container sicuri
• [ ] Casualità: Casualità crittografica da CSPRNG approvato; niente RNG ad-hoc; niente seed basati sul tempo
• [ ] Regole Nonce/IV applicate by design (unici dove richiesto; mai riutilizzati; preferibilmente generati internamente)
• [ ] Confronti Constant-time per MAC, hash e controlli uguaglianza dipendenti da segreti
• [ ] Postura Side-channel specificata (aspettative Timing/Cache/Power) e operazioni rilevanti hanno mitigazioni
• [ ] Validazione Input rigorosa e rifiuta codifiche malformate; controlli lunghezza prima dell'allocazione
• [ ] Zeroization / Lifecycle: Buffer segreti azzerati dove possibile; oggetti chiave hanno pattern di disposal deterministici
• [ ] Comportamento Errori: Fallimenti crypto restituiscono errori non rivelatori (nessun leak oracolo); chiamanti non possono distinguere branch di fallimento dipendenti da segreti
• [ ] Versioning & Agilità: Formati Protocol/Blob sono versionati; parametri codificati con ciphertext/firma dove richiesto
• [ ] Test Interoperabilita esistono (Golden Vectors o test cross-implementazione)
• [ ] Test Negativi esistono (Tamper, Replay, Truncation, Wrong Key, Wrong Nonce/IV, Wrong Context)

• [ ] Preferire AEAD (es. ChaCha20-Poly1305 / AES-GCM) su „encrypt-then-MAC“ salvo motivo specifico
• [ ] Usare Domain Separation (stringhe contesto, etichette KDF) per evitare riutilizzo Key/Nonce tra contesti
• [ ] Per Signatures/KEM: includere Context Binding (chi/cosa/perche) per prevenire attacchi di sostituzione
• [ ] Usare Codifica Strutturata (CBOR/ASN.1/Protobuf) con regole di canonicalizzazione; evitare concatenazione ambigua
• [ ] Assicurare Protezione Replay dove appropriato (numeri sequenza, timestamp con policy skew, ticket sessione)
• [ ] Non esporre direttamente primitive troppo potenti; preferire API alto livello difficili da abusare
• [ ] Assicurare Allineamento FIPS/Standard dove richiesto (documentare esplicitamente target conformità)

• [ ] Benchmark hot path; documentare trade-off Perf/Security
• [ ] Fornire guida migrazione per upgrade algoritmi (vecchio → nuovo)
• [ ] Sezione chiara „Resistenza agli Abusi“ nei docs (insidie comuni e come l'API le previene)

Versione: 2.1 (Split)
Autore: Wolfgang van der Stille

Torna a Checklist Sicurezza | Checklist di Revisione