Generare un hash SHA-256

Lo SHA-256 fa parte della famiglia SHA-2, pubblicata nel 2001, e a oggi non ha attacchi pratici né sulle collisioni né sulla preimmagine. È quello che usano i certificati TLS, la firma dei pacchetti, Bitcoin e la maggior parte delle verifiche di integrità pubblicate accanto a un file.

La sua diffusione è un argomento a sé: un algoritmo implementato ovunque, accelerato in hardware sui processori recenti e sostenuto da vent’anni di analisi è preferibile a uno più esotico e più giovane, anche a parità di robustezza dichiarata. SHA-3 esiste ed è ottimo, ma esiste come alternativa strutturalmente diversa in caso di problemi, non come sostituto necessario.

SHA-512 non è «più sicuro» di SHA-256 in nessun senso che riguardi te. Entrambi appartengono alla stessa famiglia, entrambi sono privi di attacchi pratici, e i 128 bit di resistenza alle collisioni che SHA-256 offre sono già fuori portata per qualunque avversario immaginabile.

La differenza reale è di prestazioni e dipende dall’hardware: SHA-512 lavora su parole a 64 bit ed è spesso più rapido su un processore a 64 bit, mentre SHA-256 è accelerato da istruzioni dedicate su gran parte delle CPU recenti. La scelta si fa in base a cosa si aspetta l’altra parte, che è il criterio che decide quasi sempre.

Il conto qui non lo fa un’implementazione scritta in JavaScript ma la Web Crypto API, cioè il codice crittografico nativo del browser. È la stessa strada che si sceglierebbe in un’applicazione seria: un hash reimplementato a mano è un posto in cui gli errori sono silenziosi e passano ogni test superficiale.

Ne deriva un vincolo di cui vale la pena sapere: quell’interfaccia è disponibile solo in un contesto sicuro, cioè su HTTPS o su localhost. Su una pagina servita in HTTP semplice non esiste, e uno strumento che in quel caso ripiegasse su un’implementazione propria darebbe l’impressione di funzionare uguale senza esserlo.

Duecentocinquantasei bit sono 64 caratteri esadecimali, sempre, qualunque cosa entri. La lunghezza dell’input non trapela in nessun modo nel risultato, il che è una proprietà voluta e non un effetto collaterale.

Il conteggio dei caratteri è anche il modo più rapido di capire con cosa si ha a che fare: 32 è un MD5, 40 uno SHA-1, 64 uno SHA-256, 128 uno SHA-512. Quando un valore atteso e uno ottenuto hanno lunghezze diverse, il problema non è nei dati ma nell’algoritmo, e cercare altrove è tempo buttato.

Un hash non ha nessuna tolleranza: un byte di differenza e il risultato è completamente diverso, senza nessuna somiglianza parziale che aiuti a capire quanto ci si è andati vicino. È il comportamento voluto, ed è anche quello che rende il confronto un esercizio di precisione.

Il byte colpevole è quasi sempre lo stesso: il ritorno a capo che `echo` aggiunge, o quello che l’editor mette in fondo al file. Il secondo sospettato, su Windows, è la coppia `CRLF` contro il solo `LF`: lo stesso testo salvato con due convenzioni di fine riga produce due file diversi e quindi due hash diversi, ed è il motivo per cui gli hash pubblicati accanto a un archivio vanno verificati sull’archivio e non sui file estratti.

Prima di poter calcolare qualsiasi cosa, il testo deve diventare byte, e questa pagina usa sempre UTF-8. Una `è` vale due byte, un simbolo dell’euro tre — `e2 82 ac` — e un emoji quattro.

Se stai confrontando con un sistema che lavora in Latin-1, o con del testo passato per una normalizzazione Unicode diversa, i byte sono altri e l’hash pure. Quando due implementazioni corrette danno due risultati diversi, la discussione riguarda sempre come è stato trasformato il testo e mai la funzione di hash, che su byte identici non ha margine di manovra.

Un hash lo può calcolare chiunque, perché non c’è nessun segreto in gioco. Quindi dice che un contenuto non è cambiato solo se il valore atteso ti arriva per un canale che l’attaccante non controlla: uno SHA-256 pubblicato sulla stessa pagina da cui si scarica il file non protegge da chi ha già la pagina.

Per legare un contenuto a chi lo ha prodotto serve una chiave: un HMAC, se il segreto è condiviso fra le due parti, oppure una firma asimmetrica, se chi verifica non deve poter falsificare. I webhook usano il primo e i pacchetti software il secondo, ed è il motivo per cui gli hash in quei contesti compaiono sempre dentro qualcosa di più grande.

Questa pagina lavora su una stringa perché è quello che serve a chi arriva: confrontare un valore di un database, generare un identificatore deterministico da una chiave, controllare un campo di un payload. Sono tutti casi in cui il dato è già testo e sta già in una scheda del browser.

Per un file la strada giusta è il sistema operativo, che lo legge a blocchi senza caricarlo tutto in memoria: `sha256sum` su Linux, `shasum -a 256` su macOS, `Get-FileHash` in PowerShell su Windows. Su un’immagine ISO da quattro gigabyte è l’unica strada praticabile, e gli strumenti sono già lì.

Passare un’email o un numero di telefono per uno SHA-256 non li fa uscire dall’ambito del GDPR. La funzione è pubblica e deterministica, quindi chiunque abbia una lista di candidati ritrova la corrispondenza calcolando gli stessi hash: nel linguaggio del regolamento si tratta di pseudonimizzazione, che è una misura di sicurezza e non l’uscita dal perimetro.

Diventa qualcosa di più solido con un segreto in mezzo — un HMAC con una chiave conservata separatamente — perché a quel punto la corrispondenza non è ricalcolabile da chi non ha la chiave. Resta comunque reversibile per chi ce l’ha, il che è esattamente il motivo per cui il registro dei trattamenti va scritto sulla realtà tecnica e non sulla parola «hashato».