SHA-1 vs SHA-256 : SHA-1 est mort, mais Git l'utilise encore

En bref.SHA-1 est cryptographiquement cassé — une collision pratique a été démontrée par Google en 2017 et les attaques à préfixe choisi sont devenues accessibles en 2020 — donc utilisez SHA-256 pour toute nouvelle application sécuritaire. Git utilise encore SHA-1 pour les hashes d’objets mais est en migration ; l’empreinte non sécuritaire (caches, déduplication) n’est pas affectée.

SHA-1 (sortie 160 bits, 1995) et la famille SHA-2 (sorties 256/384/512 bits, 2001) sont toutes deux des fonctions de hachage cryptographique publiées par le NIST. SHA-1 était le hash d’intégrité dominant dans les années 2000. Il est maintenant déprécié partout où la sécurité est importante — mais pas encore partout.

Les points essentiels

Comment SHA-1 a été cassé

Une fonction de hachage cryptographique doit rendre computationnellement infaisable de trouver deux entrées qui produisent le même hash. La sortie 160 bits de SHA-1 offrait une résistance aux collisions de 2⁸⁰ sur le papier — bien au-delà des budgets de force brute au moment de sa conception en 1995.

Trois jalons ont érodé cela :

1. 2005: Wang, Yin et Yu ont publié une attaque théorique réduisant la recherche de collision à ~2⁶⁹ opérations — encore infaisable à l’époque mais un avertissement clair.
2. 2017: Le projet SHAttered de Google a démontré la première collision SHA-1 pratique : deux PDFs avec le même hash SHA-1. Coût : ~110 000 $ de calcul GPU et 9 quintillions d’évaluations SHA-1.
3. 2020: Leurent et Peyrin ont publié une attaque à collision à préfixe choisi — étant donné deux en-têtes de fichier arbitraires, ajoutez des octets soigneusement forgés pour produire des fichiers en collision. Coût : ~45 000 $ en cloud. C’est le type d’attaque qui permet de forger des certificats et de falsifier des signatures en conditions réelles.

Après 2020, SHA-1 est inadapté à tout usage sécuritaire où la falsification est un enjeu.

Où SHA-1 est encore acceptable

L’empreinte non adversariale — où il n’y a aucune incitation d’un attaquant à forger des collisions — est encore correcte avec SHA-1 :

• Hashes de commits et d’objets d’arbre Git. Un attaquant forgeant une collision devrait injecter des commits forgés et les faire accepter dans les miroirs principaux. Git exécute également la détection SHA-1 des patterns d’attaque connus (la détection SHAttered) à chaque opération, rendant l’injection visible.
• Stockage adressable par contenu où vous contrôlez toutes les entrées (caches de build, déduplication CDN).

Même dans ces cas, SHA-256 est le bon défaut pour les nouveaux systèmes. L’écart de performance (SHA-256 est ~40 % plus lent que SHA-1 sur la plupart des CPU modernes) est sans importance pour presque toutes les charges de travail.

Où SHA-256 est obligatoire

• Signatures de certificats TLS. Les navigateurs ont arrêté d’accepter SHA-1 en 2017.
• Signatures JWT (HS256, RS256, ES256). Le 256 désigne SHA-256.
• Signature de code. Microsoft et Apple ont arrêté d’accepter les signatures SHA-1 vers 2016-2017.
• Partout où les attaques par collision permettraient la falsification. Signatures de documents, cryptomonnaies, preuves d’identité.

La migration Git

Git migre vers SHA-256 depuis 2018. La migration est techniquement simple mais prend du temps car chaque serveur Git, chaque système CI/CD, chaque gestionnaire de dépendances doit prendre en charge les deux. Statut en 2026 :

• Les dépôts SHA-256 fonctionnent de bout en bout sur Git moderne.
• GitHub prend en charge les dépôts SHA-256 mais utilise SHA-1 par défaut pour les nouveaux dépôts.
• GitLab et Bitbucket : support partiel, varie selon la version.
• La plupart des intégrations CI fonctionnent avec les deux.

Le comportement par défaut du CLI Git est encore SHA-1. Pour créer un dépôt SHA-256 : git init --object-format=sha256. Une fois la migration terminée — probablement en 2027-2028 — le défaut basculera.

La règle pragmatique

• Pour les nouveaux systèmes : SHA-256. Toujours. L’écart de performance n’a pas d’importance.
• Pour les systèmes SHA-1 existants : migrez quand c’est faisable, mais ne paniquez pas — la menace est réelle mais spécifique.
• Pour Git en particulier : SHA-1 convient pour l’instant. Guettez SHA-256 comme défaut.
• Pour TLS, signature de code, JWT, crypto : SHA-256 était déjà le seul choix acceptable.

Calculez les deux hashes via notre générateur de hash.

Chiffres clés

• Longueur hex : SHA-1 = 40 caractères (160 bits) ; SHA-256 = 64 caractères (256 bits) ; base64url = 27 caractères vs 43 caractères sans rembourrage.
• Résistance aux collisions par anniversaire : SHA-1 ~2⁸⁰ générique, tombé à ~2⁶¹ après l’attaque SHAttered de 2017 ; SHA-256 reste ~2¹²⁸.
• Coût SHAttered (2017) : 9 223 372 036 854 775 808 évaluations SHA-1, ~110 000 $ en temps GPU cloud, 6 500 CPU-années équivalentes.
• Attaque à préfixe choisi (Leurent & Peyrin, 2020) : ~45 000 $ sur AWS — accessible à des opérations criminelles de taille moyenne.
• Débit sur Intel SHA-NI (Ice Lake / Zen 3+) : SHA-1 ~2,1 Go/s/cœur ; SHA-256 ~1,9 Go/s/cœur — l’accélération matérielle réduit l’écart à ~10 %, pas 40 %.
• Sans accélération matérielle : SHA-1 ~700 Mo/s vs SHA-256 ~400 Mo/s — l’écart legacy ~40 % souvent cité.
• Taille de bloc : les deux utilisent des blocs de 512 bits ; SHA-1 produit un état de 160 bits, SHA-256 un état de 256 bits.
• Navigateurs en 2017 : Chrome 56, Firefox 51, Edge — tous ont arrêté d’accepter les certificats TLS SHA-1 le 24 janvier 2017.

Matrice de décision

Sources

• 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.