Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle.

Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline.

• Rainbow Table
• Come ti blocco la Rainbow Table: Il “Salt” (sale)
• Il livello successivo: Il Pepper
• Final step: L’hashing
  • PBKDF2
  • Bcrypt
  • Scrypt
  • yescrypt
  • Argon2
• Un piccolo esempio: hashing di una password con Argon2
• Gestione del pepper
• HSM
• Key / Algo Rotation
  • Caso A: Algo rotation
  • Caso B: Pepper rotation

Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password.

La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con:

• brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza,
• dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza.
• Rainbow Table: l'attacco al dizionario più insidioso di tutti

Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest.

Rainbow Table

Una Rainbow Table è un enorme dizionario pre-calcolato che contiene:

• Milioni di password comuni.
• Il relativo hash corrispondente.

Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica.

Oss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia (>120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla.

Come ti blocco la Rainbow Table: Il “Salt” (sale)

Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest.

In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi.

Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile.

Per riassumere, gli ingredienti di base sono:

1. una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico;
2. entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare;
3. salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table).

Il livello successivo: Il Pepper

È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio.

Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile.

Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il “sale”, perché non finire aggiustando con un po’ di “pepe”? Detto, fatto!

Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché:

• a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM;
• Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, “vedrà” certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave;
• il salt è diverso per ogni utente, il pepper, di solito, è unico;
• il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline.

Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato.

Va detto che l'uso del “pepper” complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. “Pepare” le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti.

Final step: L'hashing

L'ultimo punto da dettagliare è l'hash della password.

L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà:

1. resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash)
2. resistenza alla pre-immagine secondaria: dato una password p₁, deve essere impossibile trovare un'altra password p₂ t.c. H(p₁) = H(p₂) (resistenza debole alle collisioni)
3. resistenza alle collisioni: è impossibile trovare due password diverse, p₁ e p₂, t.c. H(p₁) = H(p₂) (resistenza forte alle collisioni)
4. effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash

In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti,

SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati.

Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile.

PBKDF2

È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile.

PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta.

Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli

Bcrypt

Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo.

Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware.

Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato.

Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design.

Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora).

Domina nei framework web ([Python] Django, [Ruby] Ruby on Rails, [PHP] Laravel), [Java] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio.

È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS.

È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU)

Scrypt

Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo.

Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining.

Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi.

Su Scrypt i parametri da configurare sono:

• Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria
• DImensione del blocco ®: influenza la larghezza di banda della memoria
• Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo

In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato..

Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel.

yescrypt

Piccola menzione per yescrypt, appartenente alla famiglia “Scrypt”, pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse.

Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow.

È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni.

La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici

Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima.

Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi,

Argon2

E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF.

Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF.

È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password

È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512.

Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js.

Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave.

Argon2 setta 3 parametri principali per regolare la sua forza:

• t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3)
• m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB))
• p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4)

La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria.

Un piccolo esempio: hashing di una password con Argon2

Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza.

Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden:

echo -n "Password: "; read -s PASSWORD
# Genero un Salt casuale di 128 bit
SALT=$(openssl rand -base64 128)
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

PASSWORD_HASH e SALT sono i dati che verranno archiviati e, poiché argon2 “frulla” la password con un salt, è praticamente impossibile risalire alla password originale.

La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato.

Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente.

Gestione del pepper

Col pepper le cose cambiano un pochino perché:

• deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti
• il key rotation del pepper non è banale

Mini-script che mostra come applicare salt e pepper all'hashing di una password:

# L'utente inserisce la password
echo -n "Password: "; read -s PASSWORD

# Genero un Salt casuale di 128 bit unico per ogni utente
SALT=$(openssl rand -base64 128)

# Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128"
# e si troverà in un punto esterno al database degli utenti.
PEPPER=$(get_pepper_from_ext)

# Digest della password+salt
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

# HMAC del digest con PEPPER come chiave
PASSWORD_PEPPER=$(echo "${PASSWORD_HASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64)

HSM

Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti.

L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave,

Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo.

Key / Algo Rotation

Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping.

È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni.

Caso A: Algo rotation

Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni.

Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò:

1. il digest della password “pepato”: HMAC ( pepper, HASH ( salt, password ) )
2. il salt

Il wrapping: La strategia sarà quello di “avvolgere” la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto.

1. Imponiamo il nuovo algoritmo a tutti gli utenti “imbustando” il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH_NEW: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
2. Per ogni utente averemo dunque:
   1. il nuovo digest al posto di quello vecchio,
   2. il nuovo salt
   3. il vecchio salt
3. Settiamo il flag del cambio algoritmo a true (o quello che è)
4. Quando l'utente effettuerà il login con successo e il flag sarà a “true”, abbiamo la password che ci permetterà di eliminare il vecchio “involucro” e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH_NEW ( salt_new, password ) ) e il flag ritornerà a “false“

Considerazioni:

• La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio.
• La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente.
  • Se il flag è “true” (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
  • Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH_NEW ( salt_new, password ) )

Caso B: Pepper rotation

Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest :

HMAC ( pepper, HASH ( salt, password ) )

con quello nuovo:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

mettendo il flag a “true”.

Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è “true” innanzitutto verificherò che:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con:

HMAC ( pepper_new, HASH ( salt, password ) )

memorizzandolo al posto di quello vecchio e rimettendo il flag a false.

Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste.

È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni.

#kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash

In “Come generare una password o un keyfile sicuri” abbiamo visto come generare password e keyfile che si basassero su dati il più possibile casuali. La verifica matematica di una password si basa sulla determinazione del numero di tentativi necessari a un attaccante per indovinarla. Esistono due approcci: quello teorico (brute force) e quello realistico (pattern matching).

• Calcolo teorico (Entropia di Shannon)
  • Spiegazione dell’entropia di Shannon
  • Esempi d’uso
• Calcolo realistico (pattern matching)
  • Ent
  • zxcvbn
  • Riassumendo
• Metodo Diceware

Calcolo teorico (Entropia di Shannon)

Un primo strumento per la valutazione di una password è dato dall'entropia di Shannon, che chiunque abbia usato un password manager certamente conoscerà.

Questo calcolo assume che l'attaccante non sappia nulla della nostra password e debba provare ogni possibile combinazione (forza bruta).

Dato un alfabeto di R simboli e una password di lunghezza L, l'entropia E sarà pari a:

E = log₂ ( R^L ) = L * log₂ ( R )

L'entropia è un valore numerico espresso in bit (gli “Shannon”) che rappresenta una misura, non tanto della robustezza, quanto della “densità” della password, ossia di quanto lavoro richieda ad un calcolatore per essere indovinata. Più è alta, meglio è.

Spiegazione dell'entropia di Shannon

Innanzitutto notiamo che R^L è la dimensione dello spazio di possibilità in cui esiste la mia password e, per R e L sufficientemente grandi, è un numero talmente enorme da essere difficilmente comprensibile.

L'equivalente E, che non è altro che l'esponente della potenza di 2 tale per cui 2^E = R^L, risulta invece molto più gestibile e confrontabile.

Semplificando, se alla mia password lunga L corrisponde quindi un'analoga chiave in bit lunga E, un attaccante che voglia scoprire la mia password, invece che indovinare gli L simboli da un alfabeto R, compirà lo stesso sforzo rispondendo correttamente ad un numero di domande binarie (SI / NO) pari a E, per ricostruire la giusta sequenza binaria.

Quanto costa ricostruire la sequenza? O, in altre parole, qual è lo sforzo computazionale richiesto?

Si parla di caso medio ottimale corrispondente ad una ricerca binaria in cui ogni domanda dimezza lo spazio di possibilità fino ad azzerarlo completamente.

E = L * log₂ ( R ), è quel numero di bit che mi dice quant'è profondo l'albero delle decisioni che il calcolatore deve percorrere, albero in cui il numero dei possibili cammini radice-foglia (equivalenti a tutte le possibili password) è 2^E = R^L.

• Nel caso migliore, rispondo correttamente a tutte le E domande al primo tentativo (trovo subito il mio cammino sull'albero).
• Nel caso peggiore, mi occorreranno 2^E risposte (percorro tutti i cammini dell'albero) equivalente proprio a R^L.

Possiamo allora definire formalmente l'entropia come quella quantità minima di informazione necessaria ad azzerare l'incertezza legata all'identificazione della password. Per questo motivo è espressa in bit.

Una misurazione di questo tipo ha senso solo se ipotizziamo che i simboli siano tutti equiprobabili.

La formula di Shannon misura, sì, l'entropia, ma al suo massimo potenziale, quando la distribuzione dei simboli nella sequenza è omogenea e assolutamente casuale.

Esempi d'uso

Facciamo l'esempio di una password lunga 20, costruita su un alfabeto di 66 simboli (alfanumerico con maiuscole e minuscole più 4 simboli speciali). La dimensione di questo spazio di possibilità è pari a:

S_p = R^L = 66²⁰ = 2,46 * 10³⁶

Tentare un attacco di forza bruta su un oggetto del genere è semplicemente impensabile. Faccio un esempio.

Per forzare la nostra password, supponiamo di avere a disposizione il più potente supercomputer del mondo, El Capitan ad oggi, dotato di una potenza di calcolo spaventosa, in media 2.000 exaFLOPS con picchi di 2.746 exaFLOPS, dove 1 exaFLOPS è un quintilione (10¹⁸) di operazioni al secondo.

Il calcolo di una password si misura in Hash al secondo, H/s per usare una notazione compatta, che è più dispendiosa della singola operazione.

Approssimando per eccesso con molto ottimismo e nell'ipotesi di usare algoritmi estrememente deboli e poco costosi dal punto di vista computazionale come NTLM o MD5, possiamo pensare che il nostro sistema possa arrivare a calcolare, in queste condizioni, circa 1,5 quintilioni ( 1,5 * 10¹⁸ ) H/s. Per algoritmi come bcrypt o argon2, progettati per essere molto dispendiosi, tale potenza si riduce drasticamente di molti ordini di grandezza. Da 10¹⁸ a 10⁹ – 10⁶. Ma consideriamo il caso più favorevole perché sembra appunto una potenza enorme.

Ma anche questa tremenda esibizione di potenza annichilisce di fronte al numero di calcoli da compiere nel nosro spazio di possibilità. Dato S_p lo spazio di possibilità (il numero di possibili combinazioni), il tempo T espresso in secondi necessario ad eseguire tutte le operazioni sarà:

S_p = 66²⁰ = 2,46 * 10³⁶

T = 2,46 * ³⁶ / 1,5 * 10¹⁸ = 1,64 * 10¹⁸

Che equivale a circa 52 miliardi di anni.

Per avere un'idea di questa grandezza cosmica, si pensi che l'età del nostro universo è di circa 13,8 miliardi di anni. Quindi il calcolo della nostra password potrebbe richiedere un tempo che è grossomodo 3,8 volte l'età dell'universo.

I 120 bit di entropia, sono dunque la misura di questo sforzo potenziale, interpretabile equivalentemente in due modi differenti:

• la probabilità di riuscire a trovare la password tirando a indovinare, probabilità che è 1 su 2¹²⁰

oppure

• la capacità di rispondere correttamente e consecutivamente a 120 domande di tipo (SI / NO) (ricerca del giusto cammino in un albero decisionale binario profondo 120 livelli)

Allungando la nostra password di altri due caratteri, l'entropia arriva a circa 133 e il calcolo delle possibili combinazioni, posto che fosse possibile ignorando le leggi della termodinamica, richiederebbe circa 16.500 di volte l'età dell'universo.

Considerazione a margine: è la lunghezza della password ad incidere più che la complessità dell'alfabeto. E lo vediamo dalla formula dell'entropia, perché, in una funzione di elevamento a potenza R^L, aumentare l'esponente L fa crescere molto più rapidamente la funzione che non aumentando la base R.

Calcolo realistico (pattern matching)

L'entropia di Shannon fornisce un riscontro utilizzabile solo ipotizzando che:

• le scelte siano indipendenti
• la distribuzione sia uniforme

e in uno scenario di questo tipo, l'attacco di forza bruta non è una via percorribile.

Allo stesso tempo, se non vengono rispettati questi vincoli, l'entropia dà una falsa sicurezza perché la formula di Shannon “standard” non tiene conto della ridondanza:

Consideriamo questa password: Password12345678

• teoria: la formula E = L * log2R direbbe che la sua entropia sia 95, ottima.
• realtà: poiché è una sequenza ovvia, l'attaccante la proverà per prima. La sua entropia reale sarà vicina a 0 bit.

L'entropia quindi misura la “densità” della password, la sua imprevedibilità potenziale ma non dà nessuna informazione sulla presenza di schemi ripetuti e sul pattern matching.

Ent

L'essere umano come generatore di entropia fa schifo. Ecco perché, per un attaccante, prima ancora di provare tutte le possibili combinazioni di caratteri, un attacco a dizionario può far risparmiare un sacco di tempo. Infatti sempre Shannon ci dice che nelle parole dei linguaggi naturali alcune lettere ricorrono più di altre, non serve lo stesso numero di domanda ma molto meno e così l'entropia media diminuisce. Per prevenire questi effetti collaterali, il nostro metodo di generazione e quindi ciò che viene generato, deve essere testato con qualcos'altro che non sia la semplice entropia.

ent è un tool a linea di comando che fa 4 valutazioni differenti:

• entropia
• Chi-quadrato
• Media aritmetica
• Monte Carlo Pi

N.B. ent non è adatto alla valutazione della singola password perché ha bisogno di migliaia di dati (almeno 1K). Una singola password di 24 caratteri per es. (24 byte) non ha materiale casuale sufficiente affinché ent converga verso un giudizio oggettivo.

Entropia L'entropia misura la densità di informazione. In ent, viene calcolata in bit per carattere (byte).

• Il valore: Si analizza il file byte per byte, il valore massimo è 8.0 (ogni byte è totalmente imprevedibile).
• Interpretazione: Più il valore è vicino a 8, più la casualità è “densa” e difficile da indovinare tramite attacchi basati su dizionario. Se il valore è basso (es. 2.0 o 3.0), significa che ci sono molte ripetizioni o uno schema prevedibile.
• Compressione: ent ti dice anche quanto il file potrebbe essere compresso. Un'entropia di 8.0 significa che il file è già “puro caos” e non può essere compresso ulteriormente.

Chi-quadrato Il test del chi-quadrato prova a capire se il disordine presente nel file sia veramente equo o se si preferiscono certi caratteri ad altri. Esamina la distribuzione dei caratteri e la confronta con una distribuzione uniforme teorica. Il risultato viene presentato come percentuale con questi scaglioni:

• 10% < chi² < 90%: La sequenza è considerata casuale. Il 50% è il valore “perfetto”.
• chi² < 1% o chi² > 99%: È quasi certamente non casuale.
  • chi² = 99.99%: i dati sono sospettosamente regolari;
  • chi² = 0.01%: i dati sono “troppo” casuali per essere naturali (sospetta manipolazione)

Media aritmetica Per capire se la distribuzione è sufficientemente omogenea, si fa la somma dei valori dei byte del file e si fa una media.

Poiché i byte vanno da 0 a 255, il valore ideale della media sarebbe 127,5. Se è troppo lontano dalla media avvcinandosi ad uno dei due estremi (ad es. 50 o 190), vuol dire che si sta usando solo un piccola parte dei caratteri a disposizione e questo, a suo modo di vedere, rende le password più prevedibili.

Monte Carlo Pi È il metodo più fantasioso di tutti. I dati casuali vengono trasformati in una serie di “dardi” virtuali che vanno a colpire un bersaglio. L'obiettivo non è quello di colpire un ipotico centro ma di verificare che i “dardi” si distribuiscano uniformemente nel bersaglio.

Tutto ciò si realizza immaginando di avere un quadrato 1x1 e ¼ di cerchio al suo interno di raggio 1 e area π/4 I dati della sequenza casuale vengono prelevati a gruppi di n byte e supponiamo n = 3 per ora. Ogni gruppo di 3 byte sarà un numero compreso tra 0 e 2²⁴-1. Se normalizziamo questo numero dividendolo per 2²⁴, otteniamo un numero compreso fra 0 e 1. Calcolando le coordinate in questo modo, col teorema di Pitagora possiamo verificare se la coordinata (X,Y) “cada” nel quarto di cerchio oppure no e ciò succede se:

X² + Y² ≤ 1

Lanciando un migliaio di queste “frecce”, accumuliamo dati sufficiente per fare una stima.

Se indichiamo con In il numero di “lanci” con successo e con Total il numero totale di lanci effettuati:

4 * (ln/Total) si avvicinerà a π solo se la distribuzione dei caratteri sarà uniforme (indice di una casualità omogenea), altrimenti divergerà in maniera significativa (indice della presenza di pattern o di ripetizioni).

zxcvbn

ent fa un'analisi statistica della distribuzione dei bit in un generatore di casualità.

zxcvbn invece fa un'analisi di tipo euristico, è verticale sulla verifica delle password in particolare nel rilevare se vi sono schemi o ripetizioni di caratteri che renderebbero le password violabili.

Il suo algoritmo scompone le password in pezzi dei quali cerca corrispondenze in dizionari o schemi come:

• dizionari: controlla la presenza di parole di uso comune
• sequenze: controlla la presenza di serie di caratteri prevedibili come “123456”, “abcde”
• pattern spaziali: controlla la presenza di percorsi sulla tastiera come “qwerty”, “asdfg”, “zcvbn” o sequenze diagonali
• ripetizioni: ripetizione di caratteri come “kkkkkkkkkk” o “12121212”
• l33t: una parola come “p4$$w0rd” viene subito riconosciuta come “password”
• date: riconosce giorni, mesi, anni, anche composti come “15062026”

Il suo uso è molto semplice. Le si dà in pasto la password e zxcvbn restituisce diverse informazioni utili:

• uno score da “0” (terribile) a “4 (ottima);
• la stima di quanto tempo impiegherebbe un hacker a violarla in base a vari scenari di attacco;
• suggerimenti su come migliorare eventualmente la password.

zxcvbn era una libreria javascript orginariamente sviluppata da Dropbox e ora disponibile in tante forme: go, python, c++.

L'originale Dropbox in javascript, non più manutenuto, può essere trovata qui: https://github.com/dropbox/zxcvbn.

Benché esistano diversi porting in python, se c'è l'esigenza di usare la versione legacy, gli stessi sviluppatori dell'originale zxcvbn consigliano questa versione: https://github.com/dwolfhub/zxcvbn-python, che può essere installata con pip.

In realtà la versione migliore è un fork in typescript, zxcvbn-ts che offre modularità (a differenza della versione python che è monolitica), maggior sicurezza, risoluzione di bug, aggiornamento continuo dizionari compresi.

Per capirci, mentre ent usa l'entropia di Shannon per valutare la probabilità statistica dei byte, zxcvbn cerca di calcolare una stima dei tempi necessari per indovinare la password.

Una passphrase su ent avrebbe un punteggio risibile perché le entropie di parole comuni sono molto basse. Su zxcvbn invece avrebbe un punteggio molto alto perché l'entropia di una parola viene calcolata sulla posizione del dizionario che la contiene per cui un hacker dovrebbe provare milioni di combinazioni prima di trovarla.

Allo stesso modo, password che per ent sarebbero ottime, per zxcvbn sarebbero da evitare perché legate a pattern o a ripetizioni.

Riassumendo

Se si deve testare una password / passphrase, sicuramente zxcvbn. Se si deve testare un generatore di casualità o un keyfile di almeno 2k, sicuramente ent.

Metodo Diceware

Visto che nell'ultima parte abbiamo evidenziato l'anomalia che sorge nel momento in cui si valuta un oggetto casuale o dal punto di vista puramente statistico o dal punto di vista euristico, vale la pena di spendere due parole sulla modalità di creazione delle passphrase usando il metodo Diceware.

Usando come password parole estratte dal linguaggio naturale bisogna fare i conti col problema della prevedibilità. Shannon ha dimostrato che la lingua italiana (o inglese) ha un'entropia molto bassa (circa 1-1.5 bit per lettera) perché dopo una “q” ci si aspetta quasi sempre una “u”, e dopo un soggetto ci si aspetta un verbo. E così via. Ecco perché, piuttosto che valutare l'entropia nel suo complesso e provare ogni possibile combinazione, un moderno calcolatore inzia col far ricorso a “pattern” umani per violare password in pochi minuti invece che millenni.

Per unire la sicurezza del calcolo casuale alla comodità di una password menmonica, si ricorre al metodo Diceware che consiste nel far uso di un dizionario di migliaia di parole.

Quello classico, di 7776 parole inglesi, curato dall EFF si può trovare qui:

curl -L https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt > dic_diceware.txt

Altrimenti Tarin Gamberini espone il suo dizionario diceware , aggiornato al 2019, qui: https://www.taringamberini.com/downloads/diceware_it_IT/lista-di-parole-diceware-in-italiano/4/word_list_diceware_it-IT-4.txt.

Questo dizionario contiene 6⁵ parole numerate da 11111 a 66666. La passphrase è composta da n di queste parole il cui indice è ricavato lanciando un dado (o un analogo virtuale) per 5 volte. In questo modo le parole non sono correlate fra di loro come si potrebbero trovare in una frase, vanificando ogni possibile speculazione sulla sua composizione.

Volendo fare un calcolo dell'entropia, supponendo di costruire una passphrase di 6 parole:

E = L * log₂ R = 6 * log₂ 7776 ~ 77,6

Nella password classiche basate su un alfabeto di R simboli, il mattoncino è rappresentato dal singolo carattere che ha una probabilità 1/R di essere estratto.

Con Diceware, il mattoncino è la parola che ha una probabilità su 7776 di essere estratta. Ogni parola in più, aggiunge una quantità enorme di incertezza.

Ecco perché con sole 6 parole abbiamo già una passphrase molto robusta e con 10 parole siamo di fronte ad una passphrase inattacabile, almeno dal punto di vista dell'analisi statistica (E > 129) e imperforabile anche ricorrendo ad analisi euristiche.

Regola aurea: la scelta delle parole deve essere realmente casuale e non seguire regole grammaticali o preferenze personali. Altrimenti sarà un gioco da ragazzi violarla con un approccio a-là zxcvbn.

#entropy #shannon #bruteforce #ent #zxcvbn #diceware #passphrase #PatternMatching

La generazione di una password o di un keyfile si basa sulla casualità ossia sulla capacità del sistema di generare sequenze di simboli non prevedibili. In questo contesto bisogna avere chiari 3 concetti legati fra loro: casualità, sorgente d'entropia, entropia della password.

• Definizioni varie
• Entropia del kernel (CSPRNG)
• Come generare password e keyfile
  • Analisi
  • Valutazione
  • Conclusione
• Bonus – Modalità paranoia
  • Generazione password
  • Generazione keyfile
  • GPG Random
• Riepilogo finale
  • 2) Keyfile binario
  • 3) Password complessa con caratteri stampabili
  • 5) Keyfile binario con openssl

Definizioni varie

Casualità In generale, posso parlare di casualità quando non riesco ad individuare un pattern o un'organizzazione deterministica in una sequenza di dati.

Da un punto di vista crittografico, una sequenza è considerata “casuale” se non esiste un algoritmo che possa prevedere il bit successivo con una probabilità superiore al 50% (puro caso).

Sorgente d'entropia La casualità è resa possibile dalla sorgente d'entropia che è il dispositivo o il processo fisico che genera il rumore grezzo per produrre dati casuali. È l'origine dell'incertezza e il suo grado di “purezza” è fondamentale per la produzione della casualità.

Le sorgenti di entropia possono essere fisiche (TRNG) o software (PRNG). In quest'ultimo caso si parla di pseudo-casualità perché si tratta di algoritmi che espandono un seed (un seme) casuale in una sequenza anche arbitrariamente lunga che sembra casuale.

Bit di entropia di una sequenza O entropia della sequenza, è la misura numerica di quanto sia imprevedibile la sequenza casuale di dati.

Quindi:

• la sorgente di entropia è il nostro generatore di incertezza;
• la casualità, la cui qualità dipende totalmente dalla prima, è il processo che produce la sequenza di dati;
• l'entropia, in termini di bit, che è funzione della lunghezza della sequenza e del set di simboli a disposizione, è la misura di quanto la sequenza sia crittograficamente non prevedibile.

Entropia del kernel (CSPRNG)

Su una qualunque linuxbox il protagonista per la generazione dell'entropia necessaria è ovviamente sua maestà il kernel, che è fatto per essere anche un CSPRNG, impronunciabile acronimo che sta per Cryptographically Secure Pseudo-Random Number Generator.

Il kernel infatti, già dall'avvio, raccoglie entropia (entropy harvesting), rumore casuale direttamente dall'hardware (interrupt del disco, tastiera, mouse, istruzioni CPU come RDRAND). Questi dati grezzi vengono mescolati in un serbatoio (l'entropy pool) da cui l'algoritmo (ChaCha20) pesca per espandere questi dati in un flusso infinito di dati pseudo casuali.

Per avere una misura di quanta casualità abbia il sistema possiamo ricorrere al seguente costrutto:

cat /proc/sys/kernel/random/entropy_avail

un valore da 256 in poi ci dice abbiamo entropia sufficiente per generare chiavi e quant'altro.

Finita la parte di teoria, vediamo in quanti modi possiamo generare una password bella robusta o un keyfile.

Come generare password e keyfile

Per generare sequenze di dati casuali possiamo seguire 2 vie:

1. attingere direttamente alla sorgente di entropia fornita dal kernel;
2. usare la sorgente per prelevare un seme e generare la sequenza casuale via software che è la via di openssl e di pwgen.

Modalità

1. dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none
2. head -c 4K /dev/urandom > mykey.bin
3. tr -dc '[:graph:]' < /dev/urandom | head -c 4096 > mykey.txt
4. pwgen -s 4095 1 > mykey.txt
5. openssl rand -out mykey.bin 4096

Analisi

Come si comportano questi procedimenti? Proviamo ad analizzarli.

Casualità Una prima distinzione va fatta sulla modalità di creazione della casualità.

I primi 3 metodi fanno riferimento direttamente alla sorgente senza introdurre altre stratificazioni software. Sul piano teorico, rappresentano il punto più vicino alla casualità fisica che si possa avere su un computer.

Openssl e pwgen no, sono due consumatori per /dev/urandom. Devono prima pescare un seme da /dev/urandom. Una volta ottenuto il seme, usano i propri algoritmi (quelli di openssl sono solitamente basati su AES-CTR o SHA2) per generare una sequenza infinita di numeri casuali. Pwgen fa una cosa simile ma è stato progettato di base per costruire password pronunciabili (minore entropia intrinseca).

Velocità Openssl, fra tutti, è il più veloce, soprattutto se si ha l'esigenza di produrre casualità per volumi di decine di giga o di tera. Ciò è dovuto al fatto che openssl effettua pochissime syscall per prelevare il seme per poi spremere solo la cpu che, supportando quasi certamente le istruzioni hardware AES-NI, rende il processo poco impegnativo per la cpu stessa e brutalmene efficiente. Agire solo sul kernel, pur conservando la purezza della casualità, causa un rallentamento notevole dovuto al grandissimo numero di syscall necessarie e dalla corrispondente attivazione degli algoritmi di cifratura. Inoltre, mentre dd può contare su un buffer relativamente più capiente, cat, tr, head o qualuque altro oggetto che “beva” direttamente da /dev/urandom, hanno dei buffer molto più piccoli a disposizione, 1MB vs 8-16KB, il cui rapporto funge da moltiplicatore sul numero di operazioni necessarie.

Sicurezza Tutti i procedimenti indicati, sono estremamente sicuri, anzi, crittograficamente sicuri. Fermo restando che vale sempre l'osservazione fatta sopra sulla metrica dell'entropia di una sequenza casuale: è funzione del set di caratteri e della lunghezza della sequenza. Conti alla mano, con un alfabeto di una settantina di caratteri, una sequenza di almeno 20 caratteri possiederà un'entropia di circa 120 bit che la rendono impenetrabile per gli attuali sistemi di calcolo.

Usare direttamente la sorgente d'entropia, è sicuramente più vantaggioso perché ci fidiamo del kernel. Inoltre è più isolato perché lavora a livello del kernel dove i processi utente, anche quelli malevoli, non possono accedere alle sue zone di memoria.

Openssl, pwgen e tutti quelli che sono generatori secondari, possono incorrere in quella che si diefinisce duplicazione della casualità. Se l'applicazione non è scritta bene, c'è il rischio che il processo, forkandosi, possa “duplicare” la casualità. In sostanza, i processi padre e figlio finiranno per produrre la stessa sequenza di simboli casuali. Una catastrofe. Vecchie versioni di openssl, ante 1.1.1 per es., hanno sofferto di questa anomalia.

Valutazione

I metodi 1,2,5 producono un keyfile di dati binari, quindi con un entropia enorme quasi vicina all'ottimo teorico. Come detto, openssl è mostruosamente più veloce.

Volendo essere purista, per un keyfile i metodi 1 e 2 (praticamente equivalenti) sono da preferire. Per produrre tera di dati casuali (storage, test di rete) sicuramente openssl. Se il volume non dovesse essere esagerato e siamo paranoici, anche il metodo 1 può andare bene.

Per la produzione di una password complessa con simboli stampabili (non necessariamente pronunciabile altrimenti l'entropia sarebbe ancora più bassa) il metodo 3 è da preferire da un punto di vista matematico.

Mettendo da parte openssl che fa comunque un ottimo lavoro (universalmente riconosciuto con tanto di certificazioni FIPS-2), voglio spendere due parole su pwgen. pwgen, con il flag -s, crea delle sequenze completamente randomiche su un alfabeto di 62 caratteri. Se la lunghezza della sequenza è >= 20, e quindi con un'entropia teorica di ~115-120, avremo delle password abbastanza inviolabili dagli attuali sistemi di calcolo. Usare il flag -y potrebbe sembrare una buona idea perché si forza ad estendere il set di caratteri. Sicuramente da una parte aumenta l'entropia della sequenza generata, visto che l'alfabeto è molto più vasto. Dall'altra però la forzatura va a compromettere l'uniformità della distribuzione casuale dei simboli.

Conclusione

1. password/keyfile stampabile: tr -dc '[:graph:]' < /dev/urandom | head -c [n] > mykey.txt
2. password/keyfile binario: head -c [n] /dev/urandom > mykey.bin (equivalentemente dd if=/dev/urandom of=mykey.bin bs=4096 count=1 iflag=fullblock status=none)
3. cancellazione disco: openssl rand [dim_disco] | dd of=/dev/sdX bs=1M status=progress

Bonus – Modalità paranoia

Generazione password

Se non ci fidassimo della sorgente di casualità, possiamo aggiungere alla sorgente di entropia un nostro segreto personale e “mescolarli” attraverso una funzione sha256 o sha512 rendendo il tutto ancora crittograficamente sicuro.

(head -c 4K /dev/urandom ; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret) | sha512sum | cut -d' ' -f1 > mykey.txt.

È certamente una password molto robusta per violare la quale occorrerebbe compromettere la sorgente d'entropia e indovinare il segreto personale (N.B. stiamo facendo l'ipotesi che si provi a rompere il meccanismo di generazione della chiave non che si provi l'enumerazione attraverso un attacco brute-force).

Generazione keyfile

Per produrre un keyfile di 4096 bytes con la stessa premessa, faremo uso di openssl.

1. si genera esplicitamente un seme dalla sorgente di entropia del kernel
2. come prima, con sha2 si mescola il seme con un nostro segreto
3. si dà in pasto ad openssl.

# Creiamo un seme unico mescolando /dev/urandom e il mio input con sha512
# Usiamo quel seme per generare 4KB di dati casuali "espansi"
(head -c 256 /dev/urandom; read -s -p "Per aumentare l'entropia inserisci una frase segreta o premi tasti a caso: " secret; echo "$secret") | sha512sum | cut -d " " -f1 | openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero | head -c 4096 > mykey.bin

L'errore che compare alla fine è un falso negativo, dovuto al fatto che openssl sta ancora provando a scrivere dati e head li tronca all'improvviso.

Giusto due righe di spiegazione:

1. head -c 256 /dev/urandom: preleva un po' di dati casuali “puri”
2. read -sp secret: si inserisce una password, una frase o tasti schiacciati a caso per aumentare l'entropia
3. sha512sum | cut -d " " -f1: si mescola tutto e si preleva solo l'esadecimale di 64 bytes
4. openssl enc -aes-256-ctr -pbkdf2 -pass stdin -nosalt -in /dev/zero: openssl, che riceve il seme sullo stdin, fa la sua magia producendo un fiume di dati casuali
5. head -c 4096: tronca il “fiume” alla lunghezza voluta per il nostro keyfile

Quindi:

1. Contro i bug del kernel: se la nostra sorgente d'entropia fosse compromessa e diventasse deterministica, occorrerebbe comunque conoscere il nostro segreto
2. Contro il keylogging: anche se il nostro segreto potesse essere svelato, la sorgente d'entropia garantirebbe comunque l'inviolabilità della nostra password

GPG Random

Quando si parla di paranoia, un altro ottimo candidato per produrre password e keyfile è certamente GPG. GPG non si llimita a copiare dati da /dev/urandom ma utilizza una propria libreria crittografica chiamata Libgcrypt, che implementa un generatore di numeri pseudocasuali, crittograficamente sicuro, molto sofisticato.

A differenza di ciò che abbiamo visto finora, GPG permette di impostare un livello di qualità per la casualità da produrre.

1. livello 0 (Debole): per scopi didatti, usato raramente.
2. livello 1 (Avanzato): adatto per chiavi di sessione e cifratura standard. Corrisponde ad una casualità di alta qualità
3. livello 2 (Forte): utilizzato per le chiavi a lungo termine (le chiavi private di GPG). È un livello estremamente conservativo. Se GPG valuta di non avere entropia sufficientemente fresca, si mette in attesa.

GPG non si fida ciecamente del kernel e così Libgcrypt crea un proprio pool di entropia in user space.

1. Libgcrypt pesca al solito un seme da /dev/urandom
2. il seme viene rimescolato con sha2 o aes
3. per evitare che i dati casuali finiscano sullo swap, libgcrypt usa pagine di memoria protetta (mlock)

Impostando il livello 2, libgcrypt può decidere di scartare molti più dati se ritiene che il pool di entropia non sia abbastanza “fresco”. Inoltre, in virtù della sua diffidenza, non consegna mai tutto ciò che arriva dal pool di entropia del kernel così come viene, ma viene rimescolato con sha2 o simili e al livello 2 tutto questo, oltre che avvenire con molta più intensità, avviene anche con molta più frequenza (GPG “chiede” spesso bit freschi al kernel) per scongiurare l'eventualità che un attaccante possa prevedere i bit successivi basandosi su quelli passati

Inoltre, GPG salva una parte di questa entropia “pregiata” in ~/.gnupg/random_seed per avere una base di casualità sicura dalle sessioni precedenti nel caso in cui un computer, appena avviato, non avesse ancora accumulato sufficiente entropia.

Si capisce bene come il livello di paranoia di GPG sia fuori scala ma per fortuna tutta questa potenza è totalmente nascosta sotto il cofano di GPG. Infatti per produrre il nostro keyfile binario basta:

gpg --dev-random 2 4096

Riepilogo finale

E dunque, 3 delle 5 modalità sopra descritte, la 2, la 3 e la 5, possono essere ripensate con l'entropia di GPG invee che con quella tipica del kernel.

2) Keyfile binario

• Kernel entropy

  head -c 4K /dev/urandom > mykey.bin
  

• Libgcrypt entropy

  gpg --dev-random 2 4096 -o mykey_gpg.bin
  

3) Password complessa con caratteri stampabili

• Kernel entropy

  tr -dc '[:graph:]' < /dev/urandom | head -c 4096 > mykey.txt
  

• Libgcrypt entropy

  gpg --gen-random 1 10000 | tr -dc 'A-Za-z0-9' | head -c 4096 > mykey_gpg.txt
  

5) Keyfile binario con openssl

• Kernel entropy

  openssl rand -out mykey.bin 4096
  

• Libgcrypt entropy

  (gpg --gen-random 2 128) | openssl rand -out mykey_gpg.bin -rand /dev/stdin 4096
  

#entropy #shannon #csprng #password #keyfile #dd #openssl #pwgen #AesCtr #AesNi #sha2 #gpg #bruteforce