SHA-1 è davvero rotto?

Sì — praticamente dal 2017 (SHAttered di Google ha dimostrato una collisione reale su PDF per 110.000 $ di calcolo) e drammaticamente dal 2020 (collisioni a prefisso scelto per 45.000 $). Qualsiasi caso d’uso di sicurezza in cui un attaccante trae vantaggio da un hash falsificato è vulnerabile.

Perché Git usa ancora SHA-1?

Inerzia e un modello di minaccia pragmatico. Gli hash di Git sono indirizzabili per contenuto, non token di sicurezza, e la logica di rilevamento SHAttered che Git include intercetta i pattern di attacco noti. La migrazione a SHA-256 è in corso dal 2018, ma ogni server Git e ogni strumento deve supportare entrambi, il che richiede tempo.

SHA-256 è più lento di SHA-1?

Circa il 40% più lento sulla maggior parte delle CPU moderne — circa 400 MB/s vs 700 MB/s. Entrambi sono dominati dall’I/O per qualsiasi carico di lavoro realistico, quindi la differenza raramente è significativa. L’accelerazione hardware (estensioni SHA di Intel, crypto ARMv8) riduce ulteriormente il divario.

Dove non dovrei mai usare SHA-1?

Firme di certificati TLS (i browser hanno smesso di accettarle nel 2017), firme JWT, firma del codice, firme di documenti, criptovalute, prove di identità — ovunque una collisione falsificata avvantaggerebbe un attaccante. SHA-256 o più forte è l’unico default accettabile per i nuovi sistemi.

Comparison

SHA-1 vs SHA-256: SHA-1 è obsoleto, ma Git lo usa ancora

SHA-1: non usarlo. SHA-256: sì, per tutto.

By Buğra SözeriPublished May 15, 2026

TL;DR. SHA-1 è crittograficamente rotto — una collisione pratica è stata dimostrata da Google nel 2017 e gli attacchi a prefisso scelto sono diventati accessibili nel 2020 — quindi usa SHA-256 per ogni nuova applicazione di sicurezza. Git usa ancora SHA-1 per gli hash degli oggetti ma sta migrando; le impronte digitali non di sicurezza (cache, deduplicazione) non sono interessate.

SHA-1 (output a 160 bit, 1995) e la famiglia SHA-2 (output a 256/384/512 bit, 2001) sono entrambe funzioni hash crittografiche pubblicate da NIST. SHA-1 era l’hash di integrità dominante negli anni 2000. Ora è deprecato ovunque la sicurezza sia importante — ma non ancora ovunque.

Il titolo

Proprietà	SHA-1	SHA-256
Dimensione output	160 bit (40 char hex)	256 bit (64 char hex)
Pubblicato	1995 (NIST FIPS 180-1)	2001 (NIST FIPS 180-2)
Collisione teorica	2005 (Wang et al., 2⁶⁹)	Nessuna dimostrata
Collisione pratica	2017 (Google SHAttered, ~$110K costo cloud)	Nessuna al 2026
Stato nei certificati TLS	Deprecato 2017	Standard attuale
Stato in Git	Ancora default, migrazione in corso	Opt-in tramite repo SHA-256
Velocità (x86-64)	~700 MB/s	~400 MB/s (più lento)

Come si è rotto SHA-1

Una funzione hash crittografica dovrebbe rendere computazionalmente impossibile trovare due input che producono lo stesso hash. L’output a 160 bit di SHA-1 garantiva 2⁸⁰ di resistenza alle collisioni sulla carta — ben oltre i budget di forza bruta al momento della progettazione nel 1995.

Tre tappe fondamentali hanno eroso questo:

2005: Wang, Yin e Yu hanno pubblicato un attacco teorico che riduce la ricerca di collisioni a ~2⁶⁹ operazioni — ancora non fattibile all’epoca ma un chiaro avviso.
2017: Il progetto SHAttered di Google ha dimostrato la prima collisione SHA-1 pratica: due PDF con lo stesso hash SHA-1. Costo: ~$110K di GPU in cloud e 9 quintilioni di valutazioni SHA-1.
2020: Leurent e Peyrin hanno pubblicato un attacco a collisione a prefisso scelto — dati due qualsiasi header di file arbitrari, aggiungere byte appositamente costruiti e produrre file in collisione. Costo: ~$45K di cloud. Questo è il tipo di attacco che consente certificati falsificati e firme contraffatte in natura.

Dopo il 2020, SHA-1 è inadatto per qualsiasi scopo di sicurezza in cui la contraffazione è importante.

Dove SHA-1 è ancora accettabile

Le impronte digitali non avversariali — dove non c’è incentivo da parte di un attaccante a falsificare collisioni — sono ancora accettabili con SHA-1:

Hash di commit e oggetti tree di Git.Un attaccante che falsifica una collisione dovrebbe iniettare commit costruiti e farli accettare nei mirror principali. Git esegue anche il rilevamento SHA-1 dei pattern di attacco noti (il rilevamento SHAttered) su ogni operazione, rendendo visibile l’iniezione di attacchi.
Archiviazione indirizzabile per contenuto dove controlli tutti gli input (cache di build, deduplicazione CDN).

Anche in questi casi, SHA-256 è il default corretto per i nuovi sistemi. Il divario di prestazioni (SHA-256 è ~40% più lento di SHA-1 sulla maggior parte delle CPU moderne) è irrilevante per quasi ogni carico di lavoro.

Dove SHA-256 è obbligatorio

Firme di certificati TLS. I browser hanno smesso di accettare SHA-1 nel 2017.
Firme JWT (HS256, RS256, ES256). Il 256 è SHA-256.
Firma del codice. Microsoft e Apple hanno smesso di accettare firme SHA-1 intorno al 2016-2017.
Ovunque gli attacchi di collisione consentirebbero la contraffazione. Firme di documenti, criptovalute, prove di identità.

La migrazione Git

Git sta migrando a SHA-256 dal 2018. La migrazione è tecnicamente semplice ma richiede tempo perché ogni server Git, ogni sistema CI/CD, ogni gestore di dipendenze deve supportare entrambi. Stato al 2026:

I repository SHA-256 funzionano end-to-end su Git moderno.
GitHub supporta i repo SHA-256 ma usa SHA-1 per default per i nuovi repo.
GitLab e Bitbucket: supporto parziale, varia per versione.
La maggior parte delle integrazioni CI funziona con entrambi.

Il comportamento predefinito per il CLI Git è ancora SHA-1. Per creare un repo SHA-256: git init --object-format=sha256. Una volta completata la migrazione — probabilmente nel 2027-2028 — il default si invertirà.

La regola pragmatica

Per i nuovi sistemi: SHA-256. Sempre. Il divario di prestazioni non conta.
Per i sistemi SHA-1 legacy: migra quando fattibile, ma non farti prendere dal panico — la minaccia è reale ma specifica.
Per Git nello specifico: SHA-1 va bene per ora. Attendi che SHA-256 diventi il default.
Per TLS, firma del codice, JWT, crypto: SHA-256 era già l’unica scelta accettabile.

Calcola entrambi gli hash tramite il nostro generatore di hash.

Dati numerici

Lunghezza hex: SHA-1 = 40 char (160 bit); SHA-256 = 64 char (256 bit); base64url = 27 char vs 43 char senza padding.
Resistenza alle collisioni nel compleanno: SHA-1 ~2⁸⁰ generica, scesa a ~2⁶¹ dopo l’attacco SHAttered del 2017; SHA-256 rimane ~2¹²⁸.
Costo SHAttered (2017): 9.223.372.036.854.775.808 valutazioni SHA-1, ~$110.000 in tempo GPU cloud, equivalente a 6.500 anni-CPU.
Attacco a prefisso scelto (Leurent & Peyrin, 2020): ~$45.000 su AWS — accessibile alle operazioni criminali di medie dimensioni.
Throughput su Intel SHA-NI (Ice Lake / Zen 3+): SHA-1 ~2,1 GB/s/core; SHA-256 ~1,9 GB/s/core — l’accelerazione hardware riduce il divario a ~10%, non 40%.
Senza accelerazione hardware: SHA-1 ~700 MB/s vs SHA-256 ~400 MB/s — il divario legacy del ~40% che le persone citano.
Dimensione blocco: entrambi usano blocchi a 512 bit; SHA-1 produce uno stato a 160 bit, SHA-256 uno stato a 256 bit.
Browser nel 2017: Chrome 56, Firefox 51, Edge — tutti hanno smesso di accettare certificati TLS SHA-1 il 24 gennaio 2017.

Matrice decisionale

Caso d’uso	Hash
Firma certificato TLS	SHA-256 (SHA-1 vietato)
JWT HS256/RS256/ES256	SHA-256
HMAC per la firma di richieste API	HMAC-SHA-256
Firma del codice (Authenticode, codesign)	SHA-256
Blocco Bitcoin / derivazione indirizzo	SHA-256 (doppio hash)
Hash oggetti Git (repo legacy)	SHA-1 accettabile, con rilevamento collisioni
Hash oggetti Git (nuovo repo)	SHA-256 tramite `--object-format=sha256`
ETag CDN / chiave cache	Entrambi; SHA-256 va bene sulle CPU moderne
Hashing password	Nessuno dei due — usa argon2id / bcrypt / scrypt

Fonti

NIST FIPS 180-4 — Secure Hash Standard — csrc.nist.gov/pubs/fips/180-4.
Stevens, M. et al. — The first collision for full SHA-1, CRYPTO 2017 (SHAttered) — shattered.io.
Leurent, G. & Peyrin, T. — SHA-1 is a Shambles, USENIX Security 2020 — sha-mbles.github.io.

Frequently asked questions

SHA-1 è davvero rotto?: Sì — praticamente dal 2017 (SHAttered di Google ha dimostrato una collisione reale su PDF per 110.000 $ di calcolo) e drammaticamente dal 2020 (collisioni a prefisso scelto per 45.000 $). Qualsiasi caso d’uso di sicurezza in cui un attaccante trae vantaggio da un hash falsificato è vulnerabile.
Perché Git usa ancora SHA-1?: Inerzia e un modello di minaccia pragmatico. Gli hash di Git sono indirizzabili per contenuto, non token di sicurezza, e la logica di rilevamento SHAttered che Git include intercetta i pattern di attacco noti. La migrazione a SHA-256 è in corso dal 2018, ma ogni server Git e ogni strumento deve supportare entrambi, il che richiede tempo.
SHA-256 è più lento di SHA-1?: Circa il 40% più lento sulla maggior parte delle CPU moderne — circa 400 MB/s vs 700 MB/s. Entrambi sono dominati dall’I/O per qualsiasi carico di lavoro realistico, quindi la differenza raramente è significativa. L’accelerazione hardware (estensioni SHA di Intel, crypto ARMv8) riduce ulteriormente il divario.
Dove non dovrei mai usare SHA-1?: Firme di certificati TLS (i browser hanno smesso di accettarle nel 2017), firme JWT, firma del codice, firme di documenti, criptovalute, prove di identità — ovunque una collisione falsificata avvantaggerebbe un attaccante. SHA-256 o più forte è l’unico default accettabile per i nuovi sistemi.

Published May 15, 2026