SHA-1 vs SHA-256 vs SHA-512: scegliere il giusto algoritmo di hash nel 2026

Apra un certificato TLS, un database di oggetti Git, l’intestazione di un blocco Bitcoin, un gestore di pacchetti Linux e un manifest di immagine Docker — troverà un hash SHA in ognuno. Ma non lo stesso SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: la famiglia abbraccia tre decenni, due filiere di progettazione e un attacco di collisione decisivo che ha messo fuori uso il membro più anziano in produzione.

Questa guida mappa l’intera famiglia così da poter scegliere l’algoritmo giusto per il proprio caso d’uso senza ripensamenti.

Albero decisionale rapido

Prima di entrare nei dettagli, ecco la tabella riassuntiva di cui la maggior parte degli sviluppatori ha davvero bisogno:

Situazione	Scelta migliore	Motivo
Certificato TLS/HTTPS	SHA-256 (minimo), SHA-384 per alta sicurezza	Obbligatorio dai Baseline Requirements del CA/Browser Forum
Firma JWT (HMAC o RSA)	SHA-256 (HS256/RS256)	Supporto universale; SHA-384/512 per regimi di conformità
Checksum di integrità software	SHA-256	Default di settore; ampiamente compreso
Integrità archiviale o a lungo termine	SHA-512	Output più grande, margine di sicurezza per i decenni a venire
Content addressing (IPFS, OCI)	SHA-256	Standard de facto per lo storage content-addressed
Git (lettura/scrittura repo esistenti)	SHA-1 per esistenti; SHA-256 per nuovi via `--object-format=sha256`	Git è in migrazione; SHA-1 domina ancora
Interoperabilità con Ethereum	Keccak-256 (non NIST SHA-3)	Ethereum usa la variante Keccak pre-standardizzazione
Sistemi classificati o defense-in-depth	SHA-384 o SHA-512	NSA Suite B; abbinato a AES-256-GCM
Nuovo codice, nessun vincolo legacy	SHA-3 (SHA3-256)	Filiera di progettazione diversa; nessuna vulnerabilità length-extension
Archiviazione password	Nessuno dei precedenti	Usare bcrypt, Argon2id o scrypt — SHA è troppo veloce

La famiglia SHA in sintesi

Algoritmo	Standard	Bit di output	Caratteri hex	Anno	Stato NIST	Uso principale oggi
SHA-1	FIPS 180-4	160	40	1995	Deprecato (2011), ritirato per le firme digitali	Git legacy, fingerprint
SHA-256	FIPS 180-4	256	64	2001	Corrente	TLS, JWT, Bitcoin, checksum
SHA-384	FIPS 180-4	384	96	2001	Corrente	Suite B, TLS ad alta sicurezza
SHA-512	FIPS 180-4	512	128	2001	Corrente	Archiviazione, LUKS, HMAC-SHA-512
SHA-3 (qualsiasi variante)	FIPS 202	224/256/384/512	variabile	2015	Corrente	Filiera alternativa, accelerazione hardware

SHA-1 e SHA-2 (il gruppo 256/384/512) condividono una costruzione Merkle-Damgard. SHA-3 usa una costruzione a spugna — una distinzione che conta più di quanto sembri, trattata più avanti.

SHA-1: rotto ma non morto

SHA-1 è stato il cavallo da battaglia degli anni 2000. Certificati SSL, email S/MIME, fingerprint PGP e Git vi hanno convergito tutti. Poi, nel febbraio 2017, Google e CWI Amsterdam hanno pubblicato SHAttered: un attacco di collisione chosen-prefix che produceva due distinti file PDF con hash SHA-1 identici. L’attacco ha richiesto circa 6,5 × 10^19 valutazioni SHA-1 — costoso nel 2017, abbordabile oggi con il cloud compute.

Il NIST aveva già deprecato SHA-1 per le firme digitali nel 2011 (NIST Special Publication 800-131A). La dimostrazione SHAttered ha accelerato la pulizia: i browser hanno smesso di fidarsi dei certificati TLS SHA-1 entro il 2017 e il CA/Browser Forum ha reso SHA-256 obbligatorio per le nuove emissioni.

Dove SHA-1 è ancora usato:

Database di oggetti Git: Git è stato progettato intorno a SHA-1 come hash di contenuto veloce, non come primitiva di sicurezza. Il formato del repository codifica gli ID oggetto a 40 caratteri hex. Esiste un percorso di migrazione verso SHA-256 (git init --object-format=sha256) ma l’adozione è lenta perché ogni piattaforma di hosting, ogni strumento CI e ogni clone esistente dovrebbe migrare in sincronia.
Fingerprint di sistemi legacy: Vecchi fingerprint di chiavi host SSH, fingerprint di chiavi PGP e schemi di numeri seriali di certificati espongono ancora valori SHA-1. Questi sono informativi, non critici per la sicurezza nella maggior parte dei contesti.

Cosa fare: Non usare SHA-1 per nulla di nuovo. Per Git, il rischio di collisione è basso per i flussi di lavoro tipici dello sviluppo software (un attaccante dovrebbe controllare entrambi i file nella collisione), ma i nuovi progetti con --object-format=sha256 sono la giusta direzione a lungo termine.

Genera un hash SHA-1 nel tuo browser: Generatore SHA-1.

SHA-256: il cavallo da battaglia

SHA-256 è l’algoritmo che fa girare internet nel 2026. Ogni certificato TLS emesso da una CA pubblica usa SHA-256 per il proprio hash di firma. Ogni JWT firmato con HS256, RS256 o ES256 usa SHA-256 internamente. Il proof-of-work di Bitcoin è double-SHA-256. L’hashing dei contenuti Docker è SHA-256. L’integrità dei pacchetti npm usa SHA-256.

Le ragioni sono pratiche:

Margine di sicurezza: 256 bit di output significano 2^128 operazioni per un attacco brute-force preimage — oltre qualsiasi hardware concepibile nel prevedibile futuro. Il livello di sicurezza effettivo è leggermente inferiore a causa degli attacchi di collisione birthday-bound (2^128 operazioni), ancora inattaccabile.
Accelerazione hardware: SHA-256 è implementato in silicio su ogni CPU Intel Goldmont+ (estensione SHA-NI), ogni chip Apple silicon, ogni processore ARMv8 e ASIC dedicati in apparati di rete e controller di storage. Quando viene usato il percorso hardware, il throughput di SHA-256 supera quello di molte alternative software apparentemente più veloci.
Supporto librerie ubiquo: Ogni libreria TLS, ogni libreria JWT, ogni libreria standard di ogni linguaggio implementa SHA-256. Non si incontrerà un muro di compatibilità.

Per il content addressing, la verifica dell’integrità e la maggior parte dei flussi di firma, SHA-256 è il default giusto a meno che uno standard specifico non richieda altro.

Genera un hash SHA-256 nel tuo browser: Generatore SHA-256.

SHA-384: la specialità TLS

SHA-384 è SHA-512 troncato a 384 bit. È stato creato per fornire un livello di sicurezza a 192 bit (metà della dimensione dell’output è il floor della collision resistance) ed è incluso nella crittografia NSA Suite B insieme a AES-256-GCM e chiavi a curva ellittica P-384.

Due proprietà rendono SHA-384 particolarmente attraente per TLS:

Immunità alla length-extension a questa dimensione di output: SHA-256 e SHA-512 sono vulnerabili agli attacchi length-extension — un attaccante che conosce H(secret || message) può calcolare H(secret || message || extension) senza conoscere il segreto. SHA-384 e SHA-512/256 sono troncati dallo stato interno completo, quindi la length extension non si applica. Se si usano hash SHA grezzi come MAC (invece di HMAC), SHA-384 è più sicuro.
Conformità Suite B: Le organizzazioni che devono rispettare i requisiti NSA/CNSA (Commercial National Security Algorithm) devono usare SHA-384 o SHA-512 insieme a RSA-3072+, ECDH P-384 e AES-256. Se il cliente è un’agenzia federale statunitense o un contractor che opera sotto i requisiti FIPS 140-3, SHA-384 potrebbe essere obbligatorio.

SHA-384 non è significativamente più sicuro di SHA-256 per la maggior parte dei casi d’uso — il divario pratico tra collision resistance a 128 bit e 192 bit è teorico agli attuali livelli di calcolo. Sceglierlo quando la conformità o l’abbinamento Suite B lo richiede, non per uso generico.

Genera un hash SHA-384 nel tuo browser: Generatore SHA-384.

SHA-512: quando servono più bit

SHA-512 produce un digest a 512 bit (128 caratteri hex). Sull’hardware a 64 bit è spesso più veloce di SHA-256 perché l’algoritmo opera su parole a 64 bit anziché a 32 bit — lo schedule interno di SHA-256 usa aritmetica a 32 bit, mentre SHA-512 usa aritmetica a 64 bit che si mappa più efficientemente sulle CPU moderne.

Benchmark su hardware a 64 bit (indicativi; browser Web Crypto API):

Algoritmo	Throughput approssimativo
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Nota: SHA-384 e SHA-512 condividono la stessa funzione di compressione interna, quindi girano alla stessa velocità. SHA-256 è più lento su 64 bit perché la dimensione della parola a 32 bit richiede più iterazioni per elaborare ogni blocco di messaggio da 512 bit. Su hardware a 32 bit o vincolato, SHA-256 è più veloce.

SHA-512 è adatto per:

Integrità archiviale: I checksum destinati a sopravvivere per decenni beneficiano del margine di output maggiore.
Cifratura full-disk: Linux LUKS usa SHA-512 come hash PBKDF predefinito per la derivazione delle chiavi (come componente di PBKDF2, non come hash standalone).
HMAC-SHA-512: Usato in alcuni schemi di firma JWT (HS512) e nell’autenticazione API dove sono preferibili MAC più grandi.
Generazione di grandi quantità di dati pseudocasuali: Le applicazioni che eseguono l’hash di un seed e necessitano di molti bit di output possono usare SHA-512 per ridurre il numero di chiamate hash.

Genera un hash SHA-512 nel tuo browser: Generatore SHA-512.

SHA-3: una filosofia di progettazione diversa

SHA-3 non è SHA-2 con un output più grande. È un algoritmo fondamentalmente diverso basato su una costruzione a spugna chiamata Keccak, progettata da Guido Bertoni, Joan Daemen, Michaël Peeters e Gilles Van Assche. Il NIST lo ha selezionato come vincitore di una competizione pubblica di sette anni (2007–2012) destinata a produrre una famiglia di hash che potesse servire da backup se venissero trovate debolezze nella costruzione Merkle-Damgard di SHA-2.

La costruzione a spugna funziona in modo diverso da Merkle-Damgard:

L’input viene imbottito e suddiviso in blocchi.
Ogni blocco viene applicato tramite XOR alla prima parte di un grande stato interno (il “rate”), poi l’intero stato viene permutato con la permutazione Keccak-f.
Dopo aver assorbito tutto l’input, l’output viene “sprizzato” dalla porzione rate dello stato.

Poiché l’output viene estratto solo da una parte dello stato e la porzione capacity non viene mai esposta direttamente, le costruzioni a spugna sono intrinsecamente immuni agli attacchi length-extension senza troncamento.

Varianti standard SHA-3 (FIPS 202):

Variante	Bit di output	Livello di sicurezza
SHA3-224	224	112-bit
SHA3-256	256	128-bit
SHA3-384	384	192-bit
SHA3-512	512	256-bit
SHAKE128	variabile	128-bit
SHAKE256	variabile	256-bit

SHA-3 vs SHA-2 in pratica:

SHA-3 non è ancora ampiamente distribuito nei protocolli progettati prima del 2015 — TLS, JWT e la maggior parte dell’infrastruttura internet usa ancora SHA-2. SHA-3 sta comparendo negli schemi di firma post-quantistici (CRYSTALS-Dilithium, SPHINCS+ usano SHA-3 internamente), nei nuovi design di protocollo che desiderano un backup di filiera diversa, e nell’hardware dove la permutazione Keccak si accelera bene. In software puro, SHA-3 è circa il 40% più lento di SHA-256 su x86.

Genera un hash SHA-3 nel tuo browser: Generatore SHA-3.

La distinzione Ethereum Keccak-256

Un errore critico: Ethereum non usa NIST SHA-3. Ethereum è stato progettato mentre la competizione Keccak era in corso e prima che il NIST finalizzasse FIPS 202. La Ethereum Virtual Machine usa la submission originale Keccak-256, che utilizza un padding diverso rispetto allo standard NIST SHA-3 finalizzato.

In dettaglio:

NIST SHA3-256 aggiunge padding 0x06 prima del blocco finale.
Keccak-256 originale (come usato da Ethereum) aggiunge padding 0x01.

Lo stesso input produce hash diversi. Chiamare NIST SHA3-256 e chiamare keccak256 di Ethereum non sono intercambiabili. La maggior parte dei linguaggi ha entrambi: in Python, hashlib.sha3_256() è NIST SHA-3; per Keccak-256 come lo usa Ethereum, serve una libreria come pysha3 (che implementa keccak_256). In JavaScript, la libreria js-sha3 espone entrambi. Il Generatore SHA-3 implementa NIST SHA3-256 — se si hanno bisogno di hash Ethereum Keccak-256, usare uno strumento specifico per Ethereum.

Benchmark di prestazioni

I numeri seguenti sono indicativi per il browser Web Crypto API su un laptop x86-64 moderno. Il throughput effettivo varia con hardware, dimensione del messaggio e se la piattaforma usa un percorso di accelerazione hardware.

Algoritmo	Throughput in streaming (64-bit)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Per messaggi piccoli (token API, checksum sotto pochi KB), tutti gli algoritmi completano in meno di 2 µs — la differenza è invisibile. Per dati grandi (tarball, immagini disco), SHA-384/512 battono SHA-256 sui sistemi a 64 bit perché operano su parole a 64 bit. SHA-3 è più lento in software puro; preferire SHA-2 nel codice critico per il throughput a meno che non sia disponibile l’accelerazione hardware Keccak. Il throughput di SHA-1 non è mai una ragione per usarlo.

Insidie comuni

Mismatch di codifica

SHA opera su byte. Se si fa l’hash della stringa "hello" in un browser dove JavaScript la codifica come UTF-16 anziché UTF-8, si ottiene un digest diverso rispetto a uno script Python che usa str.encode("utf-8"). Normalizzare sempre a UTF-8 prima di fare l’hash del testo.

Un pattern consistente:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Mancanza di salting per i MAC

Usare un hash SHA grezzo come codice di autenticazione del messaggio (H(secret || message)) è vulnerabile agli attacchi length-extension su SHA-256 e SHA-512. Usare HMAC (RFC 2104) invece: HMAC-SHA256(key, message). HMAC avvolge l’hash con un pad interno ed esterno con chiave che impedisce gli attacchi di estensione.

Length-extension su SHA-256

Se si costruisce una firma API come SHA256(secret + payload), un attaccante che conosce l’hash risultante può calcolare SHA256(secret + payload + attacker_extension) senza conoscere il segreto. Soluzione: usare HMAC, oppure usare SHA-3 (immune per costruzione), o usare SHA-384/SHA-512/256 (immune per troncamento).

Confondere Keccak-256 con NIST SHA-3

Come descritto sopra: Ethereum usa Keccak-256 con padding 0x01; NIST SHA3-256 usa padding 0x06. Producono output diversi dallo stesso input. Verificare quale variante implementa la propria libreria prima di integrarsi con contratti Ethereum o codifica Solidity ABI.

Usare SHA per le password

Gli algoritmi SHA sono progettati per essere veloci. Questa è esattamente la proprietà sbagliata per l’archiviazione delle password: un cluster GPU può calcolare miliardi di hash SHA-256 al secondo, rendendo pratico un attacco dizionario contro un database di password hash SHA. Per le password, usare una funzione di derivazione delle chiavi memory-hard: Argon2id (consigliata), bcrypt o scrypt. Non archiviare mai le password come hash SHA grezzi, nemmeno salati.

Domande frequenti

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

SHA-1 e SHA-256 sono entrambe funzioni hash Merkle-Damgard standardizzate in FIPS 180-4, ma SHA-256 produce un digest a 256 bit contro i 160 bit di SHA-1. Ancora più importante, SHA-1 è stato rotto: un attacco di collisione nel mondo reale (SHAttered, 2017) ha dimostrato due distinti file PDF con lo stesso hash SHA-1. SHA-256 non ha attacchi di collisione noti e fornisce un livello di collision resistance a 128 bit. Usare SHA-256 per qualsiasi cosa che richieda garanzie di integrità; non usare SHA-1 per nessun nuovo lavoro.

SHA-512 è più veloce di SHA-256?

Su hardware a 64 bit, sì, spesso del 30–40% per input grandi. SHA-512 usa l’aritmetica a parole a 64 bit, che le CPU moderne elaborano nativamente. SHA-256 usa l’aritmetica a parole a 32 bit, richiedendo il doppio delle operazioni per blocco di messaggio sullo stesso hardware. Su piattaforme a 32 bit o microcontroller vincolati, SHA-256 è più veloce. Per messaggi brevi (sotto pochi KB), la differenza è impercettibile.

Devo migrare da SHA-1 a SHA-256?

Per firme digitali, certificati TLS e firma del codice: sì, assolutamente — SHA-1 è deprecato e attivamente rotto. Per i repository Git: il percorso di migrazione esiste (git init --object-format=sha256) ma l’adozione è lenta a causa dei requisiti di coordinamento dell’ecosistema; il rischio di collisione per l’uso tipico dei repository è basso. Per fingerprint informativi (visualizzazione della chiave host SSH): l’esposizione alla sicurezza è minima, ma migrare a SHA-256 è buona igiene.

SHA-256 può essere invertito?

No. SHA-256 è una funzione unidirezionale per progettazione. Dato un hash, non è possibile recuperare matematicamente l’input originale. Ciò che gli attaccanti possono fare è eseguire un attacco dizionario o brute-force: fare l’hash di milioni di input candidati e confrontare. Per input a bassa entropia (stringhe brevi, password comuni, numeri sequenziali), le rainbow table precompilate rendono questo pratico. Per input ad alta entropia (UUID casuali, file grandi), l’inversione non è computazionalmente fattibile. È per questo che SHA da solo è inadatto per le password — serve una KDF lenta e salata.

Quando usare SHA-3 invece di SHA-2?

SHA-3 è appropriato quando: (a) si vuole un hash da una filiera di progettazione diversa come assicurazione contro future debolezze di SHA-2; (b) il proprio protocollo richiede immunità alla length-extension senza usare HMAC; (c) si stanno implementando schemi di firma post-quantistici che specificano SHA-3 internamente; oppure (d) si ha accelerazione hardware per Keccak e si ha bisogno di throughput. Per la maggior parte dei casi d’uso quotidiani (TLS, JWT, checksum), SHA-256 ha un supporto ecosistemico più ampio ed è il default pragmatico. SHA-3 non è più sicuro di SHA-2 a parità di dimensione dell’output — è una scommessa diversa sulla sicurezza a lungo termine.

Perché Ethereum usa Keccak-256 invece di NIST SHA-3?

Ethereum è stato progettato nel 2013–2014, prima che il NIST pubblicasse FIPS 202 (agosto 2015) finalizzando lo standard SHA-3. All’epoca, la submission Keccak era considerata la probabile vincitrice, e gli autori di Ethereum l’hanno usata direttamente. Quando il NIST ha finalizzato lo standard, ha cambiato il padding di separazione del dominio da 0x01 (Keccak originale) a 0x06, producendo output diversi dallo stesso input. Ethereum era già distribuito con il padding Keccak originale e non poteva cambiarlo. Quindi “Ethereum keccak256” e “NIST SHA3-256” sono algoritmi diversi nonostante condividano la stessa permutazione Keccak-f sottostante.

Prova gli strumenti: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — tutti girano nel tuo browser, nessun dato lascia il tuo dispositivo.

SHA-1 vs SHA-256 vs SHA-512: guida hash 2026