PRNG crittograficamente sicuri

Un CSPRNG deve soddisfare: (1) imprevedibilità del bit successivo: conoscendo tutti i bit precedenti, il bit successivo non può essere previsto con probabilità > 1/2 + negligible. (2) resistenza all'estensione della compromissione dello stato: conoscere lo stato attuale non rivela nulla sull'output passato.

/dev/urandom di Linux utilizza un CSPRNG inizializzato con un seed proveniente dal pool di entropia. Dopo l'inizializzazione iniziale (128 bit di entropia), è sicuro da usare anche quando il pool è «vuoto»: il CSPRNG mantiene un proprio stato interno. getrandom() è l'equivalente moderno della syscall.

Il kernel Linux 5.17+ ha sostituito il proprio CSPRNG con un'architettura basata su ChaCha20. ChaCha20 è veloce (non richiede accelerazione hardware), offre una sicurezza di 256 bit e dispone di una dimostrazione di sicurezza ben studiata. Il nonce è il contatore; la chiave proviene dal pool di entropia.

Fortuna (Ferguson e Schneier, 2003) è un'architettura CSPRNG che mantiene 32 pool di entropia e accumula continuamente entropia. Il generatore viene reinizializzato usando i pool man mano che si riempiono. È resistente agli attacchi di reimpostazione dell'RNG e di compromissione parziale dello stato.

NIST SP 800-90A includeva originariamente DUAL_EC_DRBG, basato sulle curve ellittiche. I documenti di Snowden hanno rivelato che la NSA aveva inserito una backdoor: i punti EC erano stati scelti in modo da permettere alla NSA di prevedere l'output a partire da qualsiasi seed. Non utilizzi mai DUAL_EC_DRBG. NIST lo ha rimosso nel 2014.

CTR_DRBG (NIST SP 800-90A) utilizza AES in modalità contatore come CSPRNG. Seed = chiave da 256 bit + nonce da 128 bit. Ogni chiamata fa avanzare il contatore. È ampiamente implementato in OpenSSL, BoringSSL e Windows BCrypt. È accelerato via hardware sulle CPU con AES-NI.

HASH_DRBG utilizza iterativamente una funzione di hash (SHA-256) con un valore di seed. HMAC_DRBG utilizza HMAC per il mixing. HMAC_DRBG è più semplice da implementare correttamente e viene usato in molti sistemi embedded (mbedTLS, WolfSSL).

Anche i CSPRNG devono essere reinizializzati periodicamente. CTR_DRBG ha un intervallo di reinizializzazione di 2^48 richieste. Fortuna si reinizializza usando i propri pool di entropia. Reinizializzazione manuale: aggiunga entropia fresca (byte restituiti da getrandom) allo stato del CSPRNG all'avvio e dopo fork().

Quando un processo esegue un fork, il processo padre e quello figlio ereditano lo stesso stato del CSPRNG e produrranno quindi output identici. Soluzione: chiami getrandom() per reinizializzare immediatamente il CSPRNG dopo fork(). Nelle versioni recenti, OpenSSL gestisce automaticamente questo caso tramite pthread_atfork().

import secrets key = secrets.token_bytes(32) # 256-bit key nonce = secrets.token_bytes(12) # 96-bit nonce for AES-GCM pin = secrets.randbelow(10**6) # 6-digit PIN # Never use random module for cryptography

window.crypto.getRandomValues(typedArray) è il CSPRNG del browser. Chiama la sorgente di entropia del sistema operativo. Viene usato dalla WebCrypto API per generare le chiavi. Non utilizzi mai Math.random() per la sicurezza: è un PRNG non crittografico inizializzato usando l'ora del sistema.

Quale modulo Python dovrebbe utilizzare per generare byte casuali crittografici?

I CSPRNG come ChaCha20, CTR_DRBG e Fortuna generano output imprevedibili a partire da seed di entropia. Eviti DUAL_EC_DRBG, random.random() e Math.random(). Utilizzi secrets (Python) o window.crypto (browser). Prossimo argomento: i problemi reali dell'entropia.