Generare un hash MD5

Rotto qui ha un significato preciso: si sanno costruire due documenti diversi con lo stesso MD5, e costruirli costa secondi su un portatile qualunque. La prima collisione è del 2004, e da allora la tecnica è diventata abbastanza economica da fabbricare coppie di file utilizzabili — due PDF con contenuti opposti e la stessa impronta.

Quello che non è rotto in modo altrettanto pratico è il caso inverso: dato un hash, ricavare un testo che lo produca resta un attacco costoso. La distinzione conta poco nella scelta, però: un meccanismo di sicurezza deve reggere anche quando è l’avversario a scegliere entrambi i documenti, e l’MD5 in quella situazione non regge.

Il difetto qui non è nemmeno la collisione: è la velocità. L’MD5 è progettato per essere rapidissimo, e una scheda grafica di fascia media ne calcola miliardi al secondo. Un archivio di password in MD5 si apre con un dizionario nel tempo di un caffè, e le password comuni non hanno nemmeno bisogno del dizionario, perché il loro hash è già in una tabella pubblica.

Le funzioni giuste sono quelle costruite per essere lente e per costare memoria: bcrypt, scrypt, Argon2. Non sono hash generici resi più difficili, sono un altro strumento, con un fattore di costo regolabile e un sale per ogni utente. Se stai cercando come conservare delle password, la risposta non è su questa pagina, ed è meglio dirlo che lasciarlo intuire.

Contro i danneggiamenti accidentali funziona benissimo: un file troncato durante uno scaricamento, un byte cambiato da un supporto difettoso, una copia interrotta. Nessuna di queste è un avversario, e per accorgersene 128 bit sono largamente sufficienti.

Serve anche come chiave di cache o come identificatore deterministico interno, dove l’unica proprietà richiesta è che lo stesso input dia lo stesso risultato e che input diversi tendano a darne di diversi. E resta necessario, senza alternative, dove un sistema che non puoi cambiare lo pretende: un ETag di un vecchio server, un campo di confronto in un database ereditato, un’API che non si tocca dal 2011.

Un MD5 sono sempre 128 bit, cioè 32 caratteri esadecimali. La lunghezza non dipende in nessun modo dall’input: una lettera sola e un file da tre gigabyte danno lo stesso numero di caratteri, il che significa anche che l’hash non conserva nulla della dimensione originale.

È il primo controllo da fare quando qualcosa non torna. Trentadue caratteri sono un MD5, quaranta sono uno SHA-1, sessantaquattro uno SHA-256. Se il valore che stai confrontando ha una lunghezza diversa dal tuo, l’algoritmo è diverso e il resto della ricerca è tempo perso.

La causa più frequente di due hash che dovrebbero coincidere e non coincidono è un carattere invisibile: l’a capo finale. `echo ciao | md5sum` calcola l’hash di cinque byte, perché `echo` aggiunge un ritorno a capo; qui, incollando `ciao`, i byte sono quattro. Sono due input diversi e danno due risultati completamente diversi.

Il rimedio da riga di comando è `printf %s ciao | md5sum` oppure `echo -n`. Anche parecchi editor aggiungono un a capo finale al salvataggio, e quasi tutti lo fanno per una buona ragione — il formato di un file di testo POSIX lo prevede — ma se stai confrontando l’hash di un campo di database con quello di un file, quel byte è la prima cosa da sospettare.

L’hash si calcola su byte, non su caratteri, e il testo diventa byte solo dopo aver scelto una codifica. Qui è sempre UTF-8, dove `città` sono sei byte e non cinque, perché la `à` ne occupa due: `c3 a0`.

Se un altro strumento ha usato Latin-1, quella `à` era un byte solo e l’hash è un altro. Non è un errore di nessuno dei due programmi: erano input diversi. Lo stesso vale per un dettaglio più sottile, la forma di normalizzazione Unicode — una `à` composta da lettera più accento combinante ha byte diversi da una `à` precomposta, e i due hash differiscono anche se sullo schermo sono identici.

Questa pagina fa l’hash di quello che scrivi, non di un file che carichi. È una scelta di ambito: chi arriva qui ha in mano una stringa — un valore di un database, una chiave di cache, un parametro da confrontare — e non una ISO da verificare.

Per un file il posto giusto è il sistema operativo, che lo fa senza leggere tutto in memoria: `md5sum` su Linux, `certutil -hashfile` su Windows, `md5` su macOS. Su un file da qualche gigabyte è anche l’unica strada praticabile, e sono strumenti già installati sulla macchina dove il file si trova.

Fare l’hash di un indirizzo email non lo rende anonimo. L’insieme degli indirizzi possibili è enumerabile, e chi ha una lista di email e la stessa funzione ritrova la corrispondenza confrontando gli hash. Nel linguaggio del GDPR quello è uno pseudonimo, non un dato anonimo, e resta soggetto al regolamento.

Il caso italiano è ancora più netto con il codice fiscale: si ricava da cognome, nome, data e comune di nascita con una regola pubblica, quindi l’intero spazio dei codici plausibili si può generare e passare per la stessa funzione. Un codice fiscale «protetto» da un MD5 è protetto da nulla, e chiamarlo anonimizzato in un registro dei trattamenti è un’affermazione che non regge.

L’uso più diffuso e più sano che resta all’MD5 è ridurre una stringa lunga e scomoda — una query completa, un percorso con parametri, un insieme di opzioni — a 32 caratteri buoni come nome di file o come chiave. Qui non c’è nessun avversario: nessuno guadagna niente a farti collidere due chiavi di cache.

Il rischio da tenere d’occhio non è crittografico ma pratico: se nella stringa da cui si ricava la chiave finisce anche qualcosa che dovrebbe restare fuori — un token di sessione, un identificatore utente — la cache comincia a distinguere per persona senza che nessuno l’abbia deciso, e da lì nascono sia i problemi di memoria sia quelli di dati mostrati alla persona sbagliata.