Generazione sicura di chiavi, nonce e IV

Tre valori crittografici distinti richiedono una generazione sicura: (1) Chiavi: hanno lunga durata e devono essere imprevedibili e segrete. (2) IV: sono specifici per messaggio, possono essere pubblici ma devono essere imprevedibili (CBC) o univoci (GCM). (3) Nonce: devono essere univoci per ogni utilizzo e possono essere casuali oppure no.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). Non derivi mai chiavi dalle password senza una KDF (PBKDF2/Argon2). Non riutilizzi mai le chiavi tra algoritmi o scopi diversi.

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # The library handles entropy sourcing internally

AES-CBC richiede un IV da 16 byte uniformemente casuale per ogni messaggio. Non riutilizzi mai un IV con la stessa chiave. Non utilizzi mai un contatore come IV in modalità CBC. Generi l'IV con: iv = os.urandom(16). Preannetta l'IV al ciphertext: non deve essere segreto, ma solo imprevedibile.

AES-GCM richiede un nonce univoco da 96 bit per ogni coppia (chiave, messaggio). Il riutilizzo del nonce compromette catastroficamente GCM: l'attaccante recupera la chiave di autenticazione e può falsificare i messaggi. Utilizzi un nonce casuale da 12 byte (limite del compleanno a 2^32 messaggi) oppure un contatore.

Per la cifratura ad alto volume con una singola chiave: mantenga un contatore persistente per ogni chiave. nonce = counter.to_bytes(12, "big"). Incrementi il contatore dopo ogni cifratura. Salvi il contatore in una memoria persistente: un ripristino al riavvio causa il riutilizzo.

AES-GCM-SIV e Deoxys-II sono resistenti all'uso scorretto dei nonce: il riutilizzo del nonce riduce la sicurezza a quella della cifratura deterministica (senza perdita della chiave di autenticazione). Sono consigliati quando è difficile garantire l'univocità dei nonce (sistemi distribuiti, scenari di arresto e riavvio).

Non utilizzi direttamente il materiale grezzo delle chiavi per scopi diversi. Derivi chiavi specifiche per ogni scopo: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Utilizzi un valore info diverso per ogni scopo.

Derivi chiavi specifiche per la sessione a partire da un segreto condiviso (ad esempio l'output di ECDH) utilizzando HKDF. TLS 1.3 deriva chiavi separate client/server per l'handshake e i dati dell'applicazione. Le chiavi di sessione isolano le compromissioni: conoscere una chiave di sessione non rivela nulla sulle altre.

Per archiviare una chiave in modo sicuro, la protegga con una Key Encryption Key (KEK) utilizzando AES-KW (RFC 3394) o AES-GCM. La chiave protetta può essere archiviata in un database o trasmessa. La KEK viene conservata in un HSM o in un keystore con supporto hardware (Android Keystore, Apple Secure Enclave).

Prima della distribuzione verifichi: (1) tutte le chiavi provengono da os.urandom/secrets. (2) Nessuna chiave o IV hardcoded. (3) Gli IV non vengono mai riutilizzati con la stessa chiave. (4) I nonce GCM sono univoci per ogni messaggio. (5) È definito un piano di rotazione delle chiavi. (6) La derivazione delle chiavi utilizza HKDF con stringhe info distinte.

Le chiavi richiedono una generazione realmente casuale; gli IV CBC richiedono casualità; i nonce GCM richiedono univocità. Utilizzi os.urandom/secrets, derivi le chiavi con HKDF e le protegga con KEK. Le AEAD resistenti all'uso scorretto dei nonce proteggono dal riutilizzo accidentale. Prossimo argomento: le prove a conoscenza zero.