SHA-1 vs SHA-256 vs SHA-512 : Choisir le bon algorithme de hachage en 2026

Ouvrez un certificat TLS, une base d’objets Git, un en-tête de bloc Bitcoin, un gestionnaire de paquets Linux et un manifeste d’image Docker — vous trouverez un hash SHA dans chacun d’eux. Mais pas le même SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3 : la famille s’étend sur trois décennies, deux lignées de conception et une attaque par collision déterminante qui a brisé en production le membre le plus ancien.

Ce guide cartographie l’ensemble de la famille afin que vous puissiez choisir le bon algorithme pour votre cas d’usage sans vous poser de questions inutiles.

Arbre de décision rapide

Avant d’entrer dans les détails, voici le tableau récapitulatif dont la plupart des développeurs ont réellement besoin :

Votre situation	Meilleur choix	Raison
Certificat TLS/HTTPS	SHA-256 (minimum), SHA-384 pour haute sécurité	Imposé par les Baseline Requirements du CA/Browser Forum
Signature JWT (HMAC ou RSA)	SHA-256 (HS256/RS256)	Support universel ; SHA-384/512 pour les régimes de conformité
Somme de contrôle d’intégrité logicielle	SHA-256	Défaut industriel ; largement compris
Intégrité archivistique ou longue durée	SHA-512	Sortie plus grande, marge de sécurité pour les décennies à venir
Adressage de contenu (IPFS, OCI)	SHA-256	Standard de facto pour le stockage adressé par contenu
Git (lecture/écriture de dépôts existants)	SHA-1 pour l’existant ; SHA-256 pour le nouveau via `--object-format=sha256`	Git est en migration ; SHA-1 domine encore
Interopérabilité avec Ethereum	Keccak-256 (pas NIST SHA-3)	Ethereum utilise la variante Keccak d’avant la standardisation
Défense en profondeur ou systèmes classifiés	SHA-384 ou SHA-512	NSA Suite B ; associé à AES-256-GCM
Nouveau code, sans contrainte héritée	SHA-3 (SHA3-256)	Lignée de conception différente ; pas de vulnérabilité à l’extension de longueur
Stockage de mots de passe	Aucun des précédents	Utilisez bcrypt, Argon2id ou scrypt — SHA est trop rapide

La famille SHA en un coup d’œil

Algorithme	Norme	Bits de sortie	Caractères hex	Année	Statut NIST	Usage principal aujourd’hui
SHA-1	FIPS 180-4	160	40	1995	Déprécié (2011), retiré pour les signatures numériques	Héritage Git, empreintes
SHA-256	FIPS 180-4	256	64	2001	Actuel	TLS, JWT, Bitcoin, sommes de contrôle
SHA-384	FIPS 180-4	384	96	2001	Actuel	Suite B, TLS haute sécurité
SHA-512	FIPS 180-4	512	128	2001	Actuel	Archivage, LUKS, HMAC-SHA-512
SHA-3 (toute variante)	FIPS 202	224/256/384/512	variable	2015	Actuel	Lignée alternative, accélération matérielle

SHA-1 et SHA-2 (le groupe 256/384/512) partagent une construction Merkle-Damgard. SHA-3 utilise une construction en éponge — une distinction plus importante qu’il n’y paraît, détaillée ci-dessous.

SHA-1 : cassé mais pas mort

SHA-1 était le cheval de trait des années 2000. Les certificats SSL, les e-mails S/MIME, les empreintes PGP et Git avaient tous convergé vers lui. Puis, en février 2017, Google et CWI Amsterdam ont publié SHAttered : une attaque par collision à préfixe choisi produisant deux fichiers PDF distincts avec des hashes SHA-1 identiques. L’attaque nécessitait environ 6,5 × 10^19 évaluations SHA-1 — coûteuse en 2017, abordable aujourd’hui avec le cloud.

Le NIST avait déjà déprécié SHA-1 pour les signatures numériques en 2011 (NIST Special Publication 800-131A). La démonstration de SHAttered a accéléré le nettoyage : les navigateurs ont cessé de faire confiance aux certificats TLS SHA-1 dès 2017, et le CA/Browser Forum a rendu SHA-256 obligatoire pour les nouvelles émissions.

Ce pour quoi SHA-1 est encore utilisé :

Base d’objets Git : Git a été conçu autour de SHA-1 comme hash de contenu rapide, non comme primitive de sécurité. Le format de dépôt code en dur des identifiants d’objets de 40 caractères hexadécimaux. Un chemin de migration vers SHA-256 (git init --object-format=sha256) existe, mais l’adoption est lente car chaque plateforme d’hébergement, chaque outil CI et chaque clone existant devraient migrer de façon synchronisée.
Empreintes de systèmes hérités : Les anciennes empreintes de clés SSH, empreintes de clés PGP et schémas de numéros de série de certificats exposent encore des valeurs SHA-1. Ces usages sont informationnels, non critiques pour la sécurité dans la plupart des contextes.

Que faire : N’utilisez pas SHA-1 pour quoi que ce soit de nouveau. Pour Git, le risque de collision est faible pour les flux de développement logiciel typiques (un attaquant devrait contrôler les deux fichiers de la collision), mais les nouveaux projets utilisant --object-format=sha256 sont la bonne direction à long terme.

Générez un hash SHA-1 dans votre navigateur : Générateur SHA-1.

SHA-256 : le cheval de trait

SHA-256 est l’algorithme qui fait tourner Internet en 2026. Chaque certificat TLS émis par une CA publique utilise SHA-256 comme hash de signature. Chaque JWT signé avec HS256, RS256 ou ES256 utilise SHA-256 en interne. La preuve de travail de Bitcoin est double-SHA-256. Le hachage de contenu Docker est SHA-256. L’intégrité des paquets npm utilise SHA-256.

Les raisons sont pratiques :

Marge de sécurité : 256 bits de sortie signifient 2^128 opérations pour une attaque par préimage en force brute — au-delà de tout matériel imaginable pour un avenir prévisible. Le niveau de sécurité réel est légèrement inférieur en raison des attaques par collision au sens de l’anniversaire (2^128 opérations), toujours inattaquable.
Accélération matérielle : SHA-256 est implémenté en silicium sur chaque CPU Intel Goldmont+ (extension SHA-NI), chaque puce Apple Silicon, chaque processeur ARMv8, ainsi que dans des ASICs dédiés des appliances réseau et contrôleurs de stockage. Quand le chemin matériel est emprunté, le débit de SHA-256 dépasse celui de nombreuses alternatives logicielles apparemment plus rapides.
Support bibliothèque universel : Chaque bibliothèque TLS, chaque bibliothèque JWT, chaque bibliothèque standard de chaque langage implémente SHA-256. Vous ne vous heurterez à aucun mur de compatibilité.

Pour l’adressage de contenu, la vérification d’intégrité et la plupart des flux de signature, SHA-256 est le bon défaut à moins qu’une norme spécifique n’exige autre chose.

Générez un hash SHA-256 dans votre navigateur : Générateur SHA-256.

SHA-384 : la spécialité TLS

SHA-384 est SHA-512 tronqué à 384 bits. Il a été créé pour offrir un niveau de sécurité de 192 bits (la moitié de la taille de sortie est le plancher de résistance aux collisions) et inclus dans la cryptographie NSA Suite B aux côtés de AES-256-GCM et des clés de courbe elliptique P-384.

Deux propriétés rendent SHA-384 particulièrement attractif pour TLS :

Immunité à l’extension de longueur à cette taille de sortie : SHA-256 et SHA-512 sont vulnérables aux attaques par extension de longueur — un attaquant qui connaît H(secret || message) peut calculer H(secret || message || extension) sans connaître le secret. SHA-384 et SHA-512/256 sont tronqués depuis l’état interne complet, donc l’extension de longueur ne s’applique pas. Si vous utilisez des hashes SHA bruts comme MACs (au lieu de HMAC), SHA-384 est plus sûr.
Conformité Suite B : Les organisations devant satisfaire aux exigences de la suite NSA/CNSA (Commercial National Security Algorithm) doivent utiliser SHA-384 ou SHA-512 avec RSA-3072+, ECDH P-384 et AES-256. Si votre client est une agence fédérale américaine ou un contractant opérant sous les exigences FIPS 140-3, SHA-384 peut être obligatoire.

SHA-384 n’est pas significativement plus sécurisé que SHA-256 pour la plupart des cas d’usage — l’écart pratique entre une résistance aux collisions de 128 bits et de 192 bits est théorique aux niveaux de calcul actuels. Choisissez-le lorsque la conformité ou l’association Suite B l’exige, non pour un usage générique.

Générez un hash SHA-384 dans votre navigateur : Générateur SHA-384.

SHA-512 : quand vous avez besoin de plus de bits

SHA-512 produit un condensé de 512 bits (128 caractères hexadécimaux). Sur le matériel 64 bits, il est souvent plus rapide que SHA-256 car l’algorithme opère sur des mots de 64 bits plutôt que de 32 bits — le calendrier interne de SHA-256 utilise de l’arithmétique 32 bits, tandis que celui de SHA-512 utilise de l’arithmétique 64 bits qui se mappe plus efficacement sur les processeurs modernes.

Benchmarks sur matériel 64 bits (indicatifs ; Web Crypto API navigateur) :

Algorithme	Débit approximatif
SHA-1	~600 Mo/s
SHA-256	~500 Mo/s
SHA-384	~700 Mo/s
SHA-512	~700 Mo/s
SHA-3-256	~300 Mo/s

Remarque : SHA-384 et SHA-512 partagent la même fonction de compression interne, ils s’exécutent donc à la même vitesse. SHA-256 est plus lent en 64 bits car sa taille de mot de 32 bits nécessite plus d’itérations pour traiter chaque bloc de message de 512 bits. Sur le matériel 32 bits ou contraint, SHA-256 est plus rapide.

SHA-512 convient particulièrement à :

Intégrité archivistique : Les sommes de contrôle censées survivre des décennies bénéficient de la marge plus grande offerte par la sortie.
Chiffrement intégral de disque : Linux LUKS utilise SHA-512 comme hash PBKDF de dérivation de clé par défaut (en tant que composant de PBKDF2, non comme hash autonome).
HMAC-SHA-512 : Utilisé dans certains schémas de signature JWT (HS512) et l’authentification d’API où des MACs plus grands sont préférés.
Génération de grandes quantités de données pseudo-aléatoires : Les applications qui hachent une graine et ont besoin de nombreux bits de sortie peuvent utiliser SHA-512 pour réduire le nombre d’appels de hachage.

Générez un hash SHA-512 dans votre navigateur : Générateur SHA-512.

SHA-3 : une philosophie de conception différente

SHA-3 n’est pas SHA-2 avec une sortie plus grande. C’est un algorithme fondamentalement différent basé sur une construction en éponge appelée Keccak, conçu par Guido Bertoni, Joan Daemen, Michaël Peeters et Gilles Van Assche. Le NIST l’a sélectionné comme gagnant d’une compétition publique de sept ans (2007–2012) destinée à produire une famille de hachage pouvant servir de secours si des faiblesses étaient découvertes dans la construction Merkle-Damgard de SHA-2.

La construction en éponge fonctionne différemment de Merkle-Damgard :

L’entrée est complétée et divisée en blocs.
Chaque bloc est XORé dans la première partie d’un grand état interne (le « débit »), puis l’état entier est permuté avec la permutation Keccak-f.
Après absorption de toute l’entrée, la sortie est « pressée » depuis la partie débit de l’état.

Parce que la sortie est extraite de seulement une partie de l’état, et parce que la partie capacité n’est jamais directement exposée, les constructions en éponge sont intrinsèquement immunisées contre les attaques par extension de longueur sans troncature.

Variantes standard SHA-3 (FIPS 202) :

Variante	Bits de sortie	Niveau de sécurité
SHA3-224	224	112 bits
SHA3-256	256	128 bits
SHA3-384	384	192 bits
SHA3-512	512	256 bits
SHAKE128	variable	128 bits
SHAKE256	variable	256 bits

SHA-3 vs SHA-2 en pratique :

SHA-3 n’est pas encore largement déployé dans les protocoles conçus avant 2015 — TLS, JWT et la majeure partie de l’infrastructure Internet utilisent encore SHA-2. SHA-3 fait son apparition dans les schémas de signature post-quantiques (CRYSTALS-Dilithium, SPHINCS+ utilisent SHA-3 en interne), les nouvelles conceptions de protocoles qui veulent une sauvegarde à lignée différente, et le matériel où la permutation Keccak s’accélère bien. En pur logiciel, SHA-3 est environ 40 % plus lent que SHA-256 sur x86.

Générez un hash SHA-3 dans votre navigateur : Générateur SHA-3.

La distinction Ethereum Keccak-256

Un piège critique : Ethereum n’utilise pas NIST SHA-3. Ethereum a été conçu pendant que la compétition Keccak était en cours et avant que le NIST finalise FIPS 202. La machine virtuelle Ethereum utilise la soumission Keccak-256 originale, qui emploie un rembourrage différent de la norme NIST SHA-3 finalisée.

Concrètement :

NIST SHA3-256 ajoute un rembourrage 0x06 avant le bloc final.
Keccak-256 original (tel qu’utilisé par Ethereum) ajoute un rembourrage 0x01.

La même entrée produit des hashes différents. Appeler NIST SHA3-256 et appeler keccak256 d’Ethereum ne sont pas interchangeables. La plupart des langages proposent les deux : en Python, hashlib.sha3_256() est NIST SHA-3 ; pour Keccak-256 tel qu’Ethereum l’utilise, il faut une bibliothèque comme pysha3 (qui implémente keccak_256). En JavaScript, la bibliothèque js-sha3 expose les deux. Le Générateur SHA-3 implémente NIST SHA3-256 — si vous avez besoin de hashes Ethereum Keccak-256, utilisez un outil spécifique à Ethereum.

Benchmarks de performances

Les chiffres ci-dessous sont indicatifs pour la Web Crypto API navigateur sur un portable x86-64 moderne. Le débit réel varie selon le matériel, la taille des messages et l’utilisation d’un chemin d’accélération matérielle par la plateforme.

Algorithme	Débit en flux (64 bits)
SHA-1	~600 Mo/s
SHA-256	~500 Mo/s
SHA-384	~700 Mo/s
SHA-512	~700 Mo/s
SHA-3-256	~300 Mo/s

Pour les petits messages (tokens d’API, sommes de contrôle sous quelques Ko), tous les algorithmes s’exécutent en moins de 2 µs — la différence est invisible. Pour les grandes données (archives tar, images disque), SHA-384/512 surpassent SHA-256 sur les systèmes 64 bits car ils opèrent sur des mots de 64 bits. SHA-3 est plus lent en pur logiciel ; préférez SHA-2 dans le code critique en débit sauf si l’accélération matérielle Keccak est disponible. Le débit de SHA-1 n’est jamais une raison de l’utiliser.

Pièges fréquents

Incompatibilités d’encodage

SHA opère sur des octets. Si vous hachez la chaîne "hello" dans un navigateur où JavaScript l’encode en UTF-16 plutôt qu’en UTF-8, vous obtenez un condensé différent de celui d’un script Python utilisant str.encode("utf-8"). Normalisez toujours en UTF-8 avant de hacher du texte.

Un schéma cohérent :

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

Absence de salage pour les MACs

Utiliser un hash SHA brut comme code d’authentification de message (H(secret || message)) est vulnérable aux attaques par extension de longueur sur SHA-256 et SHA-512. Utilisez HMAC (RFC 2104) à la place : HMAC-SHA256(key, message). HMAC enveloppe le hash avec un pad à clé interne et externe qui empêche les attaques par extension.

Extension de longueur sur SHA-256

Si vous construisez une signature d’API sous la forme SHA256(secret + payload), un attaquant qui connaît le hash résultant peut calculer SHA256(secret + payload + extension_attaquant) sans connaître le secret. Correction : utilisez HMAC, ou utilisez SHA-3 (immunisé par construction), ou utilisez SHA-384/SHA-512/256 (immunisé par troncature).

Confusion entre Keccak-256 et NIST SHA-3

Comme décrit ci-dessus : Ethereum utilise Keccak-256 avec le rembourrage 0x01 ; NIST SHA3-256 utilise 0x06. Ils produisent des sorties différentes à partir de la même entrée. Vérifiez quelle variante votre bibliothèque implémente avant de l’intégrer avec des contrats Ethereum ou l’encodage ABI Solidity.

Utiliser SHA pour les mots de passe

Les algorithmes SHA sont conçus pour être rapides. C’est exactement la mauvaise propriété pour le stockage des mots de passe : un cluster GPU peut calculer des milliards de hashes SHA-256 par seconde, rendant une attaque par dictionnaire contre une base de mots de passe hashés avec SHA tout à fait praticable. Pour les mots de passe, utilisez une fonction de dérivation de clé à mémoire intensive : Argon2id (recommandé), bcrypt ou scrypt. Ne stockez jamais les mots de passe sous forme de hashes SHA bruts, même salés.

Foire aux questions

Quelle est la différence entre SHA-1 et SHA-256 ?

SHA-1 et SHA-256 sont tous deux des fonctions de hachage Merkle-Damgard standardisées dans FIPS 180-4, mais SHA-256 produit un condensé de 256 bits contre 160 bits pour SHA-1. Plus important encore, SHA-1 a été cassé : une attaque par collision en conditions réelles (SHAttered, 2017) a démontré deux fichiers PDF distincts avec le même hash SHA-1. SHA-256 ne présente aucune attaque par collision connue et offre un niveau de résistance aux collisions de 128 bits. Utilisez SHA-256 pour tout ce qui requiert des garanties d’intégrité ; n’utilisez pas SHA-1 pour du nouveau travail.

SHA-512 est-il plus rapide que SHA-256 ?

Sur le matériel 64 bits, oui, souvent de 30 à 40 % pour les grandes entrées. SHA-512 utilise de l’arithmétique sur des mots de 64 bits, que les processeurs modernes traitent nativement. SHA-256 utilise de l’arithmétique sur des mots de 32 bits, nécessitant deux fois plus d’opérations par bloc de message sur le même matériel. Sur les plateformes 32 bits ou les microcontrôleurs contraints, SHA-256 est plus rapide. Pour les messages courts (sous quelques Ko), la différence est imperceptible.

Devrais-je migrer de SHA-1 vers SHA-256 ?

Pour les signatures numériques, les certificats TLS et la signature de code : oui, absolument — SHA-1 est déprécié et activement cassé. Pour les dépôts Git : le chemin de migration existe (git init --object-format=sha256) mais l’adoption est lente en raison des exigences de coordination de l’écosystème ; le risque de collision pour l’usage typique d’un dépôt est faible. Pour les empreintes informatives (affichage de clé SSH) : l’exposition à la sécurité est minimale, mais migrer vers SHA-256 est une bonne pratique d’hygiène.

SHA-256 peut-il être inversé ?

Non. SHA-256 est une fonction à sens unique par conception. Connaissant un hash, il est mathématiquement impossible de retrouver l’entrée originale. Ce que les attaquants peuvent faire, c’est mener une attaque par dictionnaire ou en force brute : hacher des millions de candidats et comparer. Pour les entrées à faible entropie (courtes chaînes, mots de passe courants, nombres séquentiels), les tables arc-en-ciel précalculées rendent cela praticable. Pour les entrées à haute entropie (UUIDs aléatoires, grands fichiers), l’inversion n’est pas faisable computationnellement. C’est pourquoi SHA seul est inapproprié pour les mots de passe — vous avez besoin d’une KDF lente et salée.

Quand devrais-je utiliser SHA-3 plutôt que SHA-2 ?

SHA-3 est approprié quand : (a) vous voulez un hash d’une lignée de conception différente comme assurance contre de futures faiblesses de SHA-2 ; (b) votre protocole nécessite une immunité à l’extension de longueur sans utiliser HMAC ; (c) vous implémentez des schémas de signature post-quantiques qui spécifient SHA-3 en interne ; ou (d) vous disposez d’une accélération matérielle pour Keccak et avez besoin de débit. Pour la plupart des cas d’usage quotidiens (TLS, JWT, sommes de contrôle), SHA-256 bénéficie d’un support plus large et reste le défaut pragmatique. SHA-3 n’est pas plus sécurisé que SHA-2 pour des tailles de sortie équivalentes — c’est un pari différent sur la sécurité à long terme.

Pourquoi Ethereum utilise-t-il Keccak-256 au lieu de NIST SHA-3 ?

Ethereum a été conçu en 2013–2014, avant que le NIST publie FIPS 202 (août 2015) finalisant la norme SHA-3. À l’époque, la soumission Keccak était considérée comme le gagnant probable, et les auteurs d’Ethereum l’ont utilisée directement. Lorsque le NIST a finalisé la norme, il a modifié le rembourrage de séparation de domaine de 0x01 (Keccak original) à 0x06, produisant des sorties différentes à partir de la même entrée. Ethereum était déjà déployé avec le rembourrage Keccak original et ne pouvait pas le changer. Ainsi, « Ethereum keccak256 » et « NIST SHA3-256 » sont des algorithmes différents malgré le fait qu’ils partagent la même permutation Keccak-f sous-jacente.

Essayez les outils : SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — tous s’exécutent dans votre navigateur, aucune donnée ne quitte votre machine.

SHA-1 vs SHA-256 vs SHA-512 : guide hachage 2026