SHA-256 vs SHA-3 oppose le pilier de la famille SHA-2 au standard fondé sur Keccak que le NIST a publié en 2015. Aucun des deux n’est cassé ni près de l’être, et tous deux offrent la même sécurité nominale pour une sortie de 256 bits. Ils diffèrent par leur conception interne, ce qui influe sur l’extension de longueur, la vitesse et la manière dont ils sont utilisés au sein d’algorithmes plus récents.
Vue d’ensemble
| SHA-256 | SHA3-256 | |
|---|---|---|
| Norme | FIPS 180-4 (famille de 2001, révision de 2015) | FIPS 202 (2015) |
| Construction | Merkle–Damgård, 64 tours d’une fonction de compression sur 32 bits | Éponge sur la permutation Keccak-f de 1600 bits, 24 tours |
| Sortie | 256 bits | 256 bits |
| Résistance aux collisions / à la préimage | 128 / 256 bits | 128 / 256 bits |
| Extension de longueur | Oui, hash(secret ‖ m) n’est pas un MAC | Non |
| Variantes à sortie extensible | Aucune | SHAKE128, SHAKE256 |
| Débit, entrées de 16 Kio, OpenSSL 3.6.5 | environ 2,85 Go/s | environ 1,01 Go/s |
| Débit, entrées de 16 octets | environ 0,17 Go/s | environ 0,07 Go/s |
| Instructions processeur | Extensions SHA d’Intel et d’AMD, SHA2 d’ARMv8 | Instructions SHA3 d’ARMv8.2 (EOR3, RAX1, XAR, BCAX) |
| Imposé par | TLS, X.509, S256 et RS256 de JOSE, etc., Bitcoin, Git (dépôts SHA-256) | ML-KEM, ML-DSA (SHAKE et SHA3), jeux SLH-DSA à base de SHAKE, Ed448 (SHAKE256) |
| Effet du calcul quantique | Grover : effort de préimage réduit au plus à sa racine carrée ; toujours approuvé | Identique |
Débit mesuré avec openssl speed -evp sur un cœur d’un Apple M4 Max, qui accélère matériellement les deux familles.
Conception
SHA-256 traite le message par blocs de 64 octets et fait passer chacun d’eux, avec l’état précédent de 256 bits, dans une fonction de compression ; l’état final est le condensat. Comme le condensat constitue la totalité de l’état interne, quiconque connaît SHA-256(x) et la longueur de x peut poursuivre le hachage et calculer SHA-256(x ‖ padding ‖ y) sans connaître x. Cette extension de longueur est sans conséquence pour les signatures et HMAC, mais elle casse les MAC naïfs comme SHA-256(key ‖ message).
SHA-3 est une éponge : elle absorbe l’entrée dans un état de 1600 bits au moyen de la permutation Keccak-f, puis essore la sortie à partir d’une partie de cet état. Pour SHA3-256, 1088 bits de l’état forment le débit (rate) et 512 bits la capacité, qui n’apparaît jamais en sortie : l’extension de longueur est donc impossible et SHA3-256(key ‖ message) est un MAC solide (le NIST normalise KMAC à cet effet). La même éponge fournit les fonctions à sortie extensible SHAKE128 et SHAKE256, que les algorithmes post-quantiques utilisent pour dériver des matrices et du bruit à partir de graines.
Le NIST a choisi Keccak en 2012, au terme d’une compétition de cinq ans lancée lorsque les attaques contre MD5 et SHA-1 ont fait craindre pour SHA-2, de structure similaire. Ces craintes ne se sont pas concrétisées : les meilleures attaques contre SHA-256 atteignent environ 31 étapes sur 64 pour les collisions, et la fonction complète ne présente aucune faiblesse. SHA-3 est donc une assurance, pas un remplaçant.
Vitesse
Sur l’Apple M4 Max, les deux familles disposent d’instructions dédiées, et pourtant SHA-256 est presque trois fois plus rapide sur les entrées longues : environ 2,85 Go/s contre 1,01 Go/s pour SHA3-256 avec OpenSSL 3.6.5, et 0,53 Go/s pour SHA3-512. Sur les processeurs x86 dotés des extensions SHA, le constat est similaire ; sur les processeurs dépourvus d’instructions de hachage, SHA-3 et SHA-256 sont plus proches, et BLAKE2 ou BLAKE3 sont plus rapides que les deux. Pour la plupart des applications, l’une comme l’autre est bien plus rapide que les entrées-sorties qui l’entourent ; la différence compte pour le hachage de très gros fichiers, les arbres de Merkle et les blockchains.
SHA3-256 n’est pas Keccak-256
Ethereum a adopté Keccak avant la version finale de FIPS 202, et FIPS 202 a ensuite modifié le remplissage (en ajoutant des bits de séparation de domaine). Les deux fonctions partagent la permutation, mais donnent des condensats sans rapport entre eux. Le keccak256 de Solidity, le RPC web3_sha3 ainsi que chaque adresse Ethereum, chaque sélecteur de fonction et chaque condensat EIP-712 utilisent Keccak-256. Appeler le SHA3-256 d’une bibliothèque dans du code Ethereum produit des résultats faux, sans la moindre erreur.
import { createHash } from "node:crypto";
import { keccak_256 } from "@noble/hashes/sha3.js";
const input = Buffer.from("abc");
console.log("SHA-256 ", createHash("sha256").update(input).digest("hex"));
console.log("SHA3-256 ", createHash("sha3-256").update(input).digest("hex"));
console.log("Keccak-256", Buffer.from(keccak_256(input)).toString("hex"));
SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA3-256 3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532
Keccak-256 4e03657aea45a94fc7d47ba826c8d667c0d1e6e33a64a036ec44f58fa12d6c45
Les valeurs SHA-256 et SHA3-256 correspondent aux exemples de FIPS 180-4 et de FIPS 202 pour « abc ».
Quand choisir l’un ou l’autre
- Interopérabilité des protocoles (TLS, certificats, JWT, SSH, Git, gestionnaires de paquets, Bitcoin) : SHA-256, car c’est ce que calcule l’autre partie.
- Hachage avec clé : HMAC-SHA256 fonctionne avec n’importe quelle fonction de la famille SHA-2 ; si vous préférez une construction simple avec clé, KMAC ou SHA-3 avec clé évitent la double passe de HMAC.
- Expansion de graines, flux aléatoires déterministes, sortie de longueur variable : SHAKE256 ou SHAKE128.
- Algorithmes post-quantiques : ce que fixe le standard en interne ; ML-KEM et ML-DSA utilisent SHA3 et SHAKE, si bien que les bibliothèques qui les implémentent incluent déjà SHA-3.
- Ethereum : Keccak-256, jamais le SHA3-256 de FIPS.
- Une seconde fonction de hachage, de structure différente, pour la défense en profondeur (par exemple le double hachage d’archives à long terme) : SHA-3 en complément de SHA-256.
- Vitesse brute sans exigence FIPS : BLAKE2 ou BLAKE3 sur les processeurs sans instructions de hachage.
Notes de migration
Changer de fonction de hachage modifie chaque condensat : c’est donc un changement de format plutôt qu’un simple remplacement de bibliothèque.
- Versionnez l’identifiant : enregistrez l’algorithme avec chaque condensat (
sha256:,sha3-256:, multihash, un OID), comme le font les systèmes adressés par contenu tels que les registres de conteneurs et SRI. - Publiez les deux pendant la transition : calculez les deux condensats, vérifiez celui que le consommateur connaît, et retirez l’ancien quand les consommateurs ont été mis à jour.
- Vérifiez les hypothèses liées à l’extension de longueur : si du code construit des MAC sous la forme
hash(secret ‖ message), passer à SHA-3 corrige le problème, mais passer à HMAC le corrige aussi pour SHA-256. - Attention à la troncature et aux encodages : les condensats circulent en hexadécimal, en base64 ou en base64url ; les encodages discordants sont plus fréquents que les algorithmes discordants.
- Ne migrez pas pour des raisons quantiques uniquement : les deux fonctions conservent une résistance à la préimage d’au moins 128 bits face à l’algorithme de Grover, et le projet de plan de transition du NIST maintient les deux en service.