Generatore di Hash Gratuito

Informazioni sulle funzioni hash

Una funzione di hash crittografica prende un input di qualsiasi dimensione e produce un output di dimensione fissa chiamato hash, digest o impronta. Lo stesso input produce sempre lo stesso hash; anche un cambiamento di un solo bit nell'input produce un hash drasticamente diverso (l'"effetto valanga"); e la funzione è computazionalmente impossibile da invertire, dato un hash, non puoi praticamente trovare l'input che l'ha prodotto. Tre proprietà di resistenza rendono una funzione di hash "crittografica": resistenza alla preimmagine (dato un hash h, è impossibile trovare un qualsiasi input m tale che hash(m) = h), resistenza alla seconda preimmagine (dato m₁, è impossibile trovare un m₂ diverso con lo stesso hash) e resistenza alle collisioni (è impossibile trovare due input distinti qualsiasi con lo stesso hash). Un hash che perde la resistenza alle collisioni può ancora essere sicuro per alcuni usi (integrità di file) ma non sicuro per altri (firme digitali). MD5 e SHA-1 sono esattamente in quel secchio: rotti per le collisioni ma resistenti alla preimmagine.

Una breve storia di MD5, SHA-1, SHA-2 e SHA-3

MD2 / MD4 / MD5 sono opera di Ron Rivest al MIT e a RSA Data Security. MD2 è stato pubblicato nel 1989; MD4 nel 1990; MD5 è stato pubblicato nel 1991 e standardizzato come RFC 1321 nell'aprile 1992. MD5 è stato l'hash dominante per un decennio, il default per le checksum di download, lo storage di password, la deduplicazione di file e i sistemi indirizzati al contenuto. Il primo allarme è suonato nel 1995 quando Hans Dobbertin ha pubblicato un attacco di collisione a tutti i round su MD4, il predecessore di MD5; la prima collisione pratica completa di MD5 è arrivata nell'agosto 2004 quando Wang e Yu hanno annunciato due messaggi da 128 byte in collisione; Vlastimil Klima ha velocizzato la ricerca di collisioni MD5 da ore a secondi su hardware comune nel 2006. Marc Stevens, lavorando con ricercatori della TU Eindhoven e dell'EPFL, ha dimostrato una collisione MD5 con prefisso scelto al 25C3 nel dicembre 2008, producendo un certificato CA RapidSSL falsificato firmato con MD5. Al tempo del malware Flame nel 2012, che ha usato una collisione MD5 per falsificare certificati Microsoft Update, MD5 era completamente rotto per qualsiasi uso sensibile alla sicurezza.

SHA ("Secure Hash Algorithm") è una famiglia della National Security Agency degli Stati Uniti. SHA-0 è stato pubblicato come FIPS 180 nel maggio 1993 e ritirato entro un anno per difetti di design non specificati. SHA-1 è seguito come FIPS 180-1 nell'aprile 1995, con un cambiamento di un solo bit nello schedule del messaggio che la NSA non ha mai spiegato pubblicamente. SHA-1 è diventato l'hash predefinito della fine degli anni '90 e degli anni 2000, usato da Git per gli hash dei commit, dai certificati SSL/TLS, da praticamente ogni schema di firma. Il primo attacco di collisione teorico è arrivato nel 2005 (Wang, Yin, Yu); una freestart collision nel 2015 (Stevens, Karpman, Peyrin); e la prima collisione SHA-1 completa è uscita il 23 febbraio 2017 come "SHAttered" (Stevens, Bursztein, Karpman, Albertini, Markov), che ha prodotto due file PDF diversi con lo stesso hash SHA-1. Nel gennaio 2020 l'attacco "SHA-1 is a Shambles" con prefisso scelto (Leurent e Peyrin, costo totale di circa USD 45 000 di noleggio GPU) ha reso la falsificazione a livello di certificato accessibile, accelerando la transizione a SHA-256 che il progetto Git aveva già iniziato a pianificare nel 2018. SHA-1 è ora formalmente deprecato dal NIST per firme digitali e certificati.

SHA-2 è la famiglia che ha sostituito SHA-1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 e SHA-512/256, pubblicata come FIPS 180-2 nell'agosto 2002. SHA-2 era un design difensivo, dimensioni di output più grandi, più round, stato interno più grande, e ventitré anni dopo resta non rotto. SHA-256 è il default moderno per firme digitali, certificati, JWT, hash dei blocchi Bitcoin, storage indirizzato al contenuto e la maggior parte della verifica di integrità dei file. SHA-3 è un design fondamentalmente diverso, la costruzione a spugna Keccak di Bertoni, Daemen, Peeters e Van Assche, selezionato attraverso una competizione NIST di cinque anni iniziata nel 2007 e vinta da Keccak nell'ottobre 2012; pubblicato come FIPS 202 nell'agosto 2015. SHA-3 non è un sostituto di SHA-2 (SHA-2 è ancora sicuro); è un'alternativa di difesa in profondità con una struttura interna completamente diversa, così che una futura rottura crittanalitica di SHA-2 non influenzerebbe necessariamente SHA-3. Questo strumento emette SHA-1, SHA-256, SHA-384 e SHA-512 (il set supportato dalla Web Crypto API) più MD5 (tramite un'implementazione JavaScript, poiché la Web Crypto API omette deliberatamente MD5).

Confronto tra algoritmi

Algoritmo	Output	Sicurezza
MD5	128-bit (32 hex chars)	Compromesso · non per la sicurezza
SHA-1	160-bit (40 hex chars)	Debole · deprecato
SHA-256	256-bit (64 hex chars)	Forte · consigliato
SHA-384	384-bit (96 hex chars)	Forte
SHA-512	512-bit (128 hex chars)	Forte

Dove si trovano gli hash crittografici

• Integrità di file e checksum. I mirror delle distribuzioni Linux pubblicano hash SHA-256 (e storicamente MD5/SHA-1) accanto ai download ISO; l'utente calcola l'hash del file scaricato e lo confronta con il valore pubblicato. Una mancata corrispondenza significa che il download è stato corrotto o manomesso. shasum, sha256sum e md5sum sono gli strumenti Unix standard.
• Storage di password, ma MAI come hash semplice. Conservare SHA-256(password) direttamente è pericoloso perché le rainbow table (mappe (password → hash) precomputate) rendono le password con hash semplice reversibili in millisecondi. Lo schema giusto è una funzione di hashing per password (KDF) con un sale per utente e un fattore di lavoro regolabile: Argon2id (RFC 9106, 2021, la raccomandazione moderna), scrypt (RFC 7914, Percival 2009) o bcrypt (Provos e Mazières, USENIX 1999). Tutti e tre combinano un sale (così che password identiche producano hash conservati diversi) con un calcolo deliberatamente costoso (così che gli attacchi brute-force siano frenati dal costo dell'hardware). Questo strumento calcola hash grezzi, utili per molte cose, ma non appropriati per lo storage di password da soli.
• Firme digitali. Firma l'hash, non i dati, i dati sono troppo lunghi per firmare efficientemente. RSA, DSA, ECDSA ed EdDSA firmano tutti un hash del messaggio. La funzione di hash usata deve essere resistente alle collisioni (altrimenti un attaccante può sostituire un messaggio in collisione); è esattamente per questo che MD5 e SHA-1 sono deprecati per le firme.
• Lo storage indirizzato al contenuto di Git. Ogni oggetto Git (blob, tree, commit, tag) è identificato dallo SHA-1 del suo contenuto. La scelta di design di Linus Torvalds del 2005 è ora nel mezzo di una transizione pluriennale a SHA-256, guidata dalla rottura delle collisioni di SHA-1. Git per Windows e Git core spediscono entrambi il supporto SHA-256; la migrazione di produzione è graduale.
• Bitcoin ed Ethereum. Bitcoin usa double-SHA-256 per gli hash dei blocchi e gli ID delle transazioni (la funzione di hash domina il costo del mining di Bitcoin, gli ASIC esistono solamente per calcolare SHA-256 velocemente). Ethereum usa Keccak-256 (il Keccak originale prima delle modifiche di standardizzazione NIST; talvolta chiamato "SHA-3 meno il cambio di padding").
• Verifica di firme JWT. I JSON Web Token sono tipicamente firmati con HMAC-SHA-256 (nome dell'algoritmo "HS256" nella spec JWT) o con RSA/ECDSA su un hash SHA-256. La firma permette al ricevitore di verificare che il token sia venuto dall'emittente e non sia stato manomesso.
• Subresource Integrity (SRI). L'attributo integrity="sha256-..." sui tag <script> e <link> permette ai browser di verificare che uno script ospitato su CDN non sia stato modificato prima di eseguirlo, una difesa contro CDN compromessi.
• Firma di richieste API. AWS Signature Version 4 usa HMAC-SHA-256 per firmare ogni richiesta API con la chiave di accesso segreta dell'utente. Questo autentica la richiesta senza inviare il segreto sul filo e impedisce gli attacchi di replay tramite timestamp.

Rottura della collisione contro rottura della preimmagine, perché MD5 è ancora usato

Una confusione comune: se MD5 è "rotto", perché md5sum è ancora distribuito su ogni distro Linux? La risposta è la distinzione tra resistenza alle collisioni (rotta in MD5) e resistenza alla preimmagine (ancora intatta in MD5). Un attacco di collisione lascia che un attaccante costruisca due input diversi con lo stesso hash; questo conta per le firme digitali (dove un attaccante può creare una coppia in collisione, far firmare uno e sostituire l'altro) e per qualsiasi applicazione in cui la funzione di hash dovrebbe legare un input specifico. Un attacco di preimmagine, al contrario, lascerebbe che un attaccante recuperi l'input originale da un hash, questo è ciò che romperebbe davvero una checksum di download, un hash di password o un identificatore indirizzato al contenuto. La resistenza alla preimmagine per MD5 non è stata rotta; i migliori attacchi di preimmagine pubblicati restano vicini al limite teorico di 2¹²⁸, computazionalmente impossibili su qualsiasi hardware esistente o previsto. Quindi MD5 (e SHA-1) restano legittimi per: verifica di integrità di file quando ti fidi della fonte dell'hash pubblicato (un attaccante che può sostituire il file presumibilmente può anche sostituire l'hash, quindi il modello di minaccia è "corruzione accidentale" non "manomissione deliberata"); chiavi di cache e deduplicazione dove controlli entrambi i lati; costruzioni HMAC (HMAC-MD5 è ancora sicuro perché la struttura di HMAC è robusta contro la debolezza di collisione di MD5, anche se HMAC-SHA-256 è preferito per nuovo codice). Dove MD5 deve essere sostituito: firme digitali, hash di certificati, ovunque un attaccante possa creare l'input.

La Web Crypto API e l'omissione deliberata di MD5

I browser moderni espongono l'hashing tramite crypto.subtle.digest(algorithm, data), una funzione asincrona che restituisce l'hash come ArrayBuffer. Algoritmi supportati: SHA-1, SHA-256, SHA-384, SHA-512. Nota cosa non c'è in quella lista: MD5 è deliberatamente omesso. Il W3C Web Crypto Working Group ha preso la decisione esplicita di lasciare fuori MD5, ragionando che qualsiasi uso di MD5 in un browser fosse o legacy (meglio gestito con un polyfill) o sbagliato (e non andrebbe reso facile). Il supporto MD5 di questo strumento viene da una piccola implementazione JavaScript (~10 KB) inclusa nella pagina; tutto il resto (SHA-1, SHA-256, SHA-384, SHA-512, più tutte le varianti HMAC) passa attraverso Web Crypto per l'elaborazione a velocità nativa. La Web Crypto API è disponibile solo in contesti sicuri (HTTPS o localhost), aprire questo strumento su HTTP semplice disabiliterebbe silenziosamente l'hashing SHA.

Formati di output: hex, Base64, Base32

Gli hash sono binari per natura, un hash di 256 bit sono 32 byte di dati opachi. Per visualizzarli o trasportarli, vengono codificati come testo. Hex (Base16) è la codifica più comune: ogni byte diventa due caratteri hex, quindi l'output SHA-256 è di 64 caratteri hex. Universale, leggibile, raddoppia la dimensione. Base64 impacchetta i byte più densamente (3 byte → 4 caratteri); SHA-256 in Base64 è 44 caratteri (con padding) o 43 (senza). Usato in JWT (la firma è codificata in Base64URL), negli attributi integrity SRI e ovunque la compattezza conti. Base32 (RFC 4648) usa 32 caratteri che escludono quelli visivamente ambigui (niente distinzione 0/O, 1/I/L); usato nelle chiavi segrete TOTP, negli ULID e negli indirizzi onion. Questo strumento emette hex per default, il formato universale che ogni altro strumento capisce.

HMAC, hashing con chiave per l'autenticazione

HMAC (Hash-based Message Authentication Code) è una costruzione definita in RFC 2104 (Krawczyk, Bellare, Canetti, febbraio 1997) che trasforma qualsiasi funzione di hash crittografica in un codice di autenticazione con chiave. La costruzione è HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), dove K' è una chiave derivata dal segreto K, e opad/ipad sono pad XOR fissi. La struttura è dimostrabilmente sicura purché lo sia l'hash sottostante, e notabilmente resta sicura anche quando l'hash sottostante ha resistenza alle collisioni debole (è per questo che HMAC-MD5 è ancora considerato sicuro, e perché HMAC-SHA1 va bene in TLS anche dopo la rottura delle collisioni di SHA-1). HMAC ha tre usi principali: firma di richieste API (AWS Signature v4, webhook GitHub, webhook Stripe), dove il ricevitore verifica che la richiesta sia venuta dal possessore del segreto; integrità JWT (HS256 = HMAC-SHA-256); e derivazione di chiavi basata su password (PBKDF2 usa HMAC internamente). La modalità HMAC di questo strumento prende una chiave segreta e produce l'HMAC dell'input sotto quella chiave.

Scope onesto: per cosa serve e per cosa non serve questo strumento

Questo strumento calcola hash crittografici grezzi di testo o file di input. Utile per: verificare download di file contro checksum pubblicate, generare identificatori indirizzati al contenuto, calcolare valori HMAC per debug API, confrontare l'integrità di due copie di un file e imparare a cosa specifici input fanno hash. Non utile per: storage di password (usa una vera funzione di hashing per password come Argon2id, scrypt o bcrypt con sale e fattore di lavoro appropriati); invertire hash (che è l'intero punto delle funzioni di hash e non è possibile per design); o generare hash SHA-3 / Keccak (questo strumento attualmente emette SHA-1, SHA-256, SHA-384 e SHA-512 dalla famiglia SHA-2, più MD5, SHA-3 è nella lista delle funzionalità future); generare hash BLAKE2 o BLAKE3. Per BLAKE3 (l'hash moderno ad alta produttività per storage indirizzato al contenuto), usa la CLI dedicata; per lo storage di password, usa direttamente la libreria bcrypt/scrypt/Argon2id della tua applicazione.

Privacy: perché conta il solo browser qui

Calcolare l'hash di un file su un server richiede di caricare il file. Per la verifica ordinaria di download questo è irrilevante, ti fidi già della fonte. Per calcolare l'hash di documenti interni, ID scansionati, screenshot di UI in fase di lavorazione o qualsiasi file che non vorresti vedere copiato sul disco rigido di uno sconosciuto, l'hashing lato server è una falla. Questo strumento legge il file direttamente nel tuo browser usando la File API e ne calcola l'hash localmente, niente lascia il tuo dispositivo. Verifica aprendo il pannello Network di DevTools mentre clicchi Hash o metti la pagina offline (modalità aereo) dopo il caricamento e conferma che lo strumento continua a funzionare. La Web Crypto API richiede HTTPS ma non richiede accesso di rete a runtime.

Domande frequenti

A cosa serve MD5 se è compromesso?

MD5 è ancora ampiamente utilizzato per scopi non relativi alla sicurezza: controlli di integrità dei file (verifica dei download), deduplicazione, chiavi di cache e checksum. Non dovrebbe mai essere utilizzato per l'hashing delle password o per le firme digitali.

Posso invertire un hash per ottenere il testo originale?

No. Le funzioni hash sono progettate per essere unidirezionali. Tuttavia, gli aggressori utilizzano tabelle precalcolate (rainbow table) per cercare hash comuni. Per questo motivo le password devono essere hashate con funzioni hash lente e salate come bcrypt, non con SHA-256 grezzo.

Il mio file viene caricato quando ne calcolo l'hash?

No. Il file viene letto direttamente nel tuo browser utilizzando File API e hashato localmente utilizzando Web Crypto API (per SHA) o un'implementazione JavaScript pura (per MD5). Nulla viene inviato ad alcun server.

Qual è la differenza tra SHA-256 e SHA-3?

SHA-256 fa parte della famiglia SHA-2 (FIPS 180-2, agosto 2002), costruzione Merkle-Damgård, progettato dalla NSA. SHA-3 (FIPS 202, agosto 2015) è la famiglia Keccak, costruzione a spugna, progettata da Bertoni, Daemen, Peeters e Van Assche, selezionata attraverso una competizione NIST pubblica. SHA-3 non è un sostituto di SHA-2 (SHA-2 è ancora sicuro); è un'alternativa di difesa in profondità con una struttura interna fondamentalmente diversa, così che una rottura ipotetica futura di SHA-2 non influenzerebbe necessariamente SHA-3. Per nuove applicazioni nel 2026, SHA-256 è ancora il default giusto; SHA-3 è sempre più usato in Ethereum e negli schemi post-quantici. Questo strumento attualmente supporta SHA-2 (SHA-1 / 256 / 384 / 512); SHA-3 è nella lista delle funzionalità future.

Cos'è HMAC e quando ne ho bisogno?

HMAC (Hash-based Message Authentication Code, RFC 2104, 1997) è una costruzione di hash con chiave che dimostra che un messaggio è stato creato da qualcuno che conosce un segreto condiviso. Ne hai bisogno ogni volta che stai verificando che una richiesta sia venuta dalla parte giusta, verificare le firme di webhook GitHub (il segreto è la chiave di firma del webhook), le firme di webhook Stripe, le firme di richieste AWS API (Signature v4 è HMAC-SHA-256) o le firme JWT (HS256 = HMAC-SHA-256). HMAC resta sicuro anche quando l'hash sottostante ha resistenza alle collisioni debole, è per questo che HMAC-MD5 è ancora considerato sicuro, anche se HMAC-SHA-256 è il default moderno per nuovo codice.

Il mio file viene caricato quando ne calcolo l'hash?

No. Il file viene letto direttamente nel tuo browser usando la File API e ne viene calcolato l'hash localmente, tramite la Web Crypto API per gli algoritmi della famiglia SHA, tramite una piccola implementazione JavaScript per MD5. Niente attraversa la rete, verifica nel pannello Network di DevTools mentre calcoli o metti la pagina offline dopo il caricamento. Sicuro per calcolare l'hash di documenti interni, ID scansionati, screenshot di UI in lavorazione o qualsiasi file che non vorresti vedere copiato sul disco rigido di uno sconosciuto.

Strumenti correlati