Entropia (Shannon)

Entropia nella teoria dell’informazione (entropia di Shannon) misura quanto sia imprevedibile una variabile casuale, in bit. Una sorgente di entropia a 1 bit può produrre 2 risultati ugualmente probabili; n bit di entropia possono produrre 2ⁿ risultati. Matematicamente: H = log₂(N) per N risultati ugualmente probabili.

Esempi:

• Lancio di una moneta equa: 1 bit.
• Lancio di un dado equo: log₂(6) ≈ 2,58 bit.
• Password casuale di 8 caratteri minuscoli: 8 × log₂(26) ≈ 37,6 bit.
• Password casuale di 16 caratteri da [a-z A-Z 0-9 simboli]: 16 × log₂(94) ≈ 104,9 bit.
• UUID v4: 122 bit (6 bit sono costanti di versione/variante).

Perché l’entropia conta per i segreti: un attaccante che forza brutalmente la tua password prova combinazioni una alla volta. Il lavoro atteso è 2ⁿ⁻¹ tentativi, dove n è l’entropia della tua password. A un miliardo di tentativi al secondo:

• 40 bit: ~9 minuti per la forzatura. Inadeguato.
• 60 bit: ~17 anni. Marginale.
• 80 bit: ~38 milioni di anni. Adeguato.
• 128 bit: morte termica dell’universo prima dell’esaurimento. Grado crittografico.

Errore comune: l’entropia dipende dalla distribuzione, non solo dal valore. Una password “casuale” scelta da un essere umano (“Password123!”) ha molta meno entropia di quanto suggerisca la sua lunghezza, perché il processo di selezione umano non è uniforme. Le password casuali generate dal computer (tramite crypto.getRandomValues o /dev/urandom) raggiungono la piena entropia teorica del loro charset.

Usa il nostro generatore di password per vedere il misuratore di entropia in tempo reale mentre regoli lunghezza e classi di caratteri.

Esempio pratico

Tre password per lo stesso account immaginario, classificate per entropia Shannon. Prima: Password123! — 12 caratteri, sembra “forte” in lunghezza, ma la struttura (parola del dizionario + cifre sequenziali + punteggiatura ovvia) riduce l’entropia effettiva a circa 20-25 bit perché gli attaccanti usano dizionari basati su regole (hashcat’s best64, OneRuleToRuleThemAll) che provano esattamente questo schema. Decifrabile in meno di un minuto. Seconda: una passphrase Diceware come correct horse battery staple — quattro parole dalla lista Diceware di 7.776 voci, entropia = 4 × log₂(7776) ≈ 51,7 bit. Resistente agli attacchi a dizionario per anni su una singola GPU. Terza: 16 caratteri casuali da un alfabeto di 94 caratteri tramite crypto.getRandomValues: 16 × log₂(94) ≈ 104,8 bit. Computazionalmente infattibile da forzare con qualsiasi tecnologia attuale o prevedibile. La lezione: l’entropia viene dal processo di generazione, non dall’aspetto complicato.

Una sottigliezza importante: l’entropia non è uguale alla lunghezza. Una password di 30 caratteri estratta solo da lettere minuscole ha 30 × log₂(26) ≈ 141 bit — forte. Ma una “password” di 30 caratteri che è in realtà una citazione da un libro famoso ha forse 20-30 bit perché lo spazio di ricerca è il catalogo delle citazioni famose, non ogni possibile stringa di 30 caratteri. Gli attaccanti puntano alla distribuzione effettiva, non a quella nominale.

Quando e perché è importante

L’entropia è importante ogni volta che un segreto deve resistere ai tentativi di indovinarlo: password, chiavi API, token di sessione, chiavi di crittografia e i seed per qualsiasi operazione crittografica. NIST SP 800-63B (le linee guida moderne sulle password) raccomanda esplicitamente di puntare a un minimo di 80 bit per i segreti a lungo termine e 128 bit per le chiavi crittografiche. L’errore più comune è generare valori “casuali” usando Math.random() — che è un PRNG non crittografico con al massimo 52 bit di stato effettivo e prevedibile banalmente da pochi output. Per qualsiasi casualità rilevante per la sicurezza, usa crypto.getRandomValues() nei browser, crypto.randomBytes() in Node, secrets.token_*() in Python, o SecureRandom in Java/JVM. Il secondo errore è riutilizzare un token di sessione o un nonce tra sessioni multiple; anche un valore a 128 bit riutilizzato indebolisce il sistema. Riferimento: NIST SP 800-63B — Digital Identity Guidelines.

Sorgenti di entropia hardware vs software: i sistemi operativi moderni raccolgono entropia da rumore fisico — jitter di tastiera, movimenti del mouse, tempi di arrivo dei pacchetti di rete e, sulle CPU recenti, istruzioni dedicate al rumore termico (RDRAND su Intel, RDSEED su AMD). Il /dev/random di Linux storicamente si bloccava quando il pool di entropia si esauriva; /dev/urandom mescola il pool tramite un CSPRNG e non si blocca mai. Da Linux 5.18 (2022) i due sono essenzialmente equivalenti — entrambi sicuri per uso crittografico una volta raccolta l’entropia al boot. Le VM cloud e i container possono avere poca entropia al boot; la generazione di chiavi crittografiche su una VM appena avviata è uno dei pochi casi rimanenti in cui attendere brevemente l’accumulo di entropia ha importanza misurabile. Riferimento: RFC 4086 — Randomness Requirements for Security.