Le 8 octobre 2026, le NIST (National Institute of Standards and Technology) a publié un projet de révision de la Special Publication 800-185, le texte qui encadre quatre fonctions dérivées de SHA-3 : cSHAKE, KMAC, TupleHash et ParallelHash. C’est la première mise à jour de ce document depuis sa publication finale en décembre 2016. Le texte, encore au stade de brouillon, ouvre une période de commentaires publics jusqu’au 7 décembre 2026, soit exactement soixante jours. Derrière cette annonce technique se cache un chantier plus large : le NIST avait déjà prévenu, dès mars 2025, qu’il allait aussi revoir la norme FIPS 202, celle qui définit SHA-3 lui-même. Pour les développeurs, les éditeurs de bibliothèques cryptographiques et les équipes sécurité qui s’appuient sur la famille Keccak, ce n’est pas un détail administratif : la révision change la façon dont ces fonctions traitent les flux de données, avec des conséquences directes sur le chiffrement de gros volumes, l’authentification de messages et, en toile de fond, la transition post-quantique.
Ce que le NIST a publié le 8 octobre 2026
Le document s’appelle officiellement SP 800-185 Révision 1 (brouillon initial), et il porte le même sous-titre que la version de 2016 : “SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash”. Il a été créé le 5 octobre et mis à jour le 8 octobre, selon les métadonnées publiées par le centre de ressources sécurité du NIST (CSRC). Trois auteurs signent cette révision : John Kelsey, Ray Perlner et Meltem Sönmez Turan, tous chercheurs au NIST. Deux d’entre eux, Kelsey et Perlner, avaient déjà cosigné le texte original en 2016 avec Shu-jen Chang, qui n’apparaît plus sur cette nouvelle version.
Le brouillon inclut aussi un appel formel aux détenteurs de brevets, une étape classique dans le processus de normalisation du NIST avant qu’un texte ne devienne définitif. Les commentaires doivent être envoyés par courriel avant le 7 décembre, après quoi l’agence analysera les retours et publiera, selon toute vraisemblance, une seconde version avant la finalisation.
cSHAKE, KMAC, TupleHash, ParallelHash : quatre fonctions, quatre usages
Les quatre fonctions couvertes par SP 800-185 dérivent toutes de l’algorithme Keccak, le même bloc de construction que SHA-3, et figurent parmi les primitives recensées sur la page officielle du projet Hash Functions du NIST. Chacune est définie pour deux niveaux de sécurité, 128 et 256 bits, et chacune répond à un besoin précis que le SHA-3 classique ne couvre pas directement.
cSHAKE et KMAC, les deux fonctions les plus reprises
cSHAKE est une variante personnalisable de SHAKE, la fonction à sortie extensible définie dans FIPS 202. Elle permet d’ajouter une chaîne de séparation de domaine, ce qui évite qu’un même message produise la même empreinte dans deux contextes différents. KMAC (Keccak Message Authentication Code) est un code d’authentification de message à longueur variable, construit sur Keccak, qui peut aussi servir de fonction pseudo-aléatoire. C’est la fonction la mieux implantée des quatre : OpenSSL 3.x la propose déjà via son système de fournisseurs cryptographiques.
TupleHash et ParallelHash, des outils de niche
TupleHash hache des séquences de chaînes sans ambiguïté de concaténation : elle garantit que hacher (“AB”, “C”) ne produit pas la même empreinte que hacher (“A”, “BC”), un piège classique quand on construit sa propre logique de hachage. ParallelHash, elle, découpe un très long message en blocs traités en parallèle, utile pour l’intégrité de fichiers volumineux. Ce sont les deux fonctions les moins visibles en production aujourd’hui : elles ne figurent pas dans le module hashlib de Python, pas davantage parmi les noms d’algorithmes standards de Java JCA, et Go les traite dans un paquet séparé plutôt que dans sa bibliothèque de hachage principale.
La vraie nouveauté : un mode de streaming pour les fonctions à sortie extensible
Le changement technique central de cette révision ne touche pas aux algorithmes eux-mêmes, mais à la façon de les appeler. La Révision 1 ajoute une interface de traitement en flux pour les calculs de fonctions à sortie extensible (XOF), qui permet à une application de fournir des données et de réclamer une sortie progressivement, sans connaître à l’avance la longueur totale de l’entrée ou de la sortie. Concrètement, le texte introduit trois opérations : INIT, ABSORB et SQUEEZE.
Pour cSHAKE, KMAC et ParallelHash, l’opération ABSORB est cumulative : appeler ABSORB(X1) puis ABSORB(X2) revient exactement à appeler ABSORB une seule fois sur la concaténation de X1 et X2. TupleHash fonctionne différemment : chaque appel à ABSORB traite un élément complet du tuple, pas un simple fragment de données. Le NIST le signale lui-même dans le texte et demande aux relecteurs si cette différence de comportement risque de prêter à confusion, un aveu assez rare dans un document normatif.
Point important pour la compatibilité : les interfaces à appel unique, celles que les bibliothèques utilisent aujourd’hui, restent identiques à la version 2016. Aucune application existante n’a donc besoin de changer son code pour rester conforme, le streaming n’est qu’une option supplémentaire.
Voici, à titre d’illustration, la logique que décrit le brouillon pour une fonction comme cSHAKE en mode flux (pseudocode simplifié, à ne pas utiliser tel quel en production) :
etat = INIT(fonction="cSHAKE", securite=256, nom="", personnalisation="app-x")
ABSORB(etat, bloc_donnees_1)
ABSORB(etat, bloc_donnees_2) // equivalent a ABSORB(bloc_1 || bloc_2) en un seul appel
sortie_partielle_1 = SQUEEZE(etat, 32) // 32 octets demandes
sortie_partielle_2 = SQUEEZE(etat, 32) // on peut continuer a demander de la sortie
Pourquoi réviser un texte vieux de dix ans
SP 800-185 n’avait pas été retouché depuis sa publication finale en décembre 2016, après un brouillon diffusé en août de la même année. Dix ans plus tard, les usages ont changé : le traitement de flux continus, que ce soit pour chiffrer des sauvegardes massives, vérifier l’intégrité de journaux applicatifs qui grossissent en temps réel, ou traiter des flux réseau dont la taille n’est pas connue à l’avance, est devenu un cas d’usage courant. Or la version originale obligeait à charger l’intégralité des données en mémoire avant de lancer le calcul, ou à bricoler des solutions de contournement propres à chaque bibliothèque. L’interface INIT/ABSORB/SQUEEZE standardise enfin ce comportement au niveau de la norme elle-même, plutôt que de le laisser à la discrétion de chaque éditeur.
Cette mise à jour s’inscrit aussi dans une révision plus large de l’écosystème SHA-3. Le NIST ne modernise pas ces quatre fonctions isolément, il revoit l’ensemble de la famille née du concours Keccak.
FIPS 202 aussi dans le viseur du NIST
La page officielle de FIPS 202, la norme qui définit SHA-3 lui-même, porte une note de planification datée du 13 mars 2025 : le NIST y annonce sa décision de mettre à jour cette publication, parue en août 2015. La même page signale au passage une coquille repérée dans l’annexe B non normative, à la page 26, qui sera corrigée dans la prochaine révision. Cette correction mineure n’a rien d’alarmant, mais elle confirme que FIPS 202 et SP 800-185 avancent sur le même calendrier de modernisation, probablement pour que les deux textes restent cohérents une fois publiés dans leur version finale.
Pour les équipes qui suivent la cryptographie post-quantique, ce calendrier rappelle celui qui a précédé la finalisation de ML-KEM et ML-DSA : plusieurs textes connexes avancent en parallèle avant de converger.
SHA-3 face à SHA-256 : qui domine réellement en production
La disponibilité d’un algorithme dans une bibliothèque ne garantit pas son adoption dans les protocoles. C’est précisément le cas de la famille SHA-3 : largement implémentée, mais loin de dominer le trafic réel. TLS 1.3 s’appuie encore massivement sur SHA-256 et SHA-384 pour sa construction HKDF et le hachage de transcription, et SHA-3, SHAKE, cSHAKE ou KMAC n’y figurent pas comme choix négociés de façon courante.
| Écosystème | SHA-256 | SHA-3 / SHAKE | KMAC / cSHAKE | TupleHash / ParallelHash |
|---|---|---|---|---|
| Python (hashlib) | Natif, sha256() | Natif depuis Python 3.9 (via OpenSSL) | Absent de l’API standard | Absent de l’API standard |
| OpenSSL 3.x | Support complet et optimisé | Support complet | Disponible via les fournisseurs (providers) | Non exposé en standard |
| Java JCA | Algorithme standard | SHA3-256, SHAKE256 exposés | Dépend du fournisseur installé | Dépend du fournisseur installé |
| Go | Paquet standard crypto/sha256 | Paquet séparé (x/crypto/sha3) | Disponible dans le même paquet séparé | Rarement exposé |
| TLS 1.3 (négociation) | Dominant (HKDF, transcript) | Non négocié en pratique | Non négocié en pratique | Non utilisé |
Le constat est net : SHA-256 reste la fonction de hachage la plus profondément ancrée dans les protocoles existants, les certificats et les formats de fichiers, tandis que la famille SHA-3 progresse surtout comme brique disponible dans les bibliothèques, pas encore comme standard négocié au quotidien. Sur les performances pures, aucun tableau de référence public et reproductible ne permet de comparer de façon fiable le débit de SHA-256 et de SHA-3 en mégaoctets par seconde : le résultat dépend trop du processeur, de la présence d’extensions matérielles comme les instructions SHA d’Intel, et de l’implémentation logicielle utilisée. Les comparatifs qui annoncent un chiffre unique et universel doivent être pris avec prudence.
Notre comparatif SHA-256 vs SHA-3 détaille déjà ces écarts de débit mesurés dans des conditions précises, et notre analyse de BLAKE3 face à SHA-3 montre qu’un troisième concurrent, plus récent, cherche lui aussi sa place sur ce terrain.
Keccak-256 d’Ethereum n’est pas le SHA3-256 du NIST
Cette confusion revient régulièrement, y compris chez des développeurs expérimentés, et elle mérite d’être clarifiée à l’occasion de cette révision. Ethereum utilise Keccak-256 pour ses adresses de compte, ses hachages de transaction, ses arbres d’état et ses hachages de code. Cette fonction repose sur la même permutation Keccak-f[1600] que le SHA3-256 du NIST, mais les deux ne produisent pas la même empreinte pour une entrée identique.
La différence tient à une règle de bourrage (padding) changée lors de la standardisation : Ethereum a conservé le bourrage original de la proposition Keccak, tandis que le NIST a modifié cette règle en finalisant FIPS 202, en ajoutant un suffixe de séparation de domaine. En pratique, un appel nommé “SHA3-256” dans une bibliothèque standard ne reproduira jamais les adresses ou les hachages de transaction Ethereum, et inversement. Toute équipe qui porte du code entre un environnement blockchain et un environnement conforme aux normes NIST doit vérifier explicitement quelle variante de Keccak sa bibliothèque implémente, sous peine de corrompre silencieusement des données censées être identiques.
Comparatif technique des quatre fonctions SP 800-185
Le tableau suivant résume les quatre fonctions couvertes par la révision, leur usage principal et leur statut vis-à-vis du nouveau mode de streaming.
| Fonction | Type | Niveaux de sécurité | Usage principal | Comportement ABSORB en mode streaming |
|---|---|---|---|---|
| cSHAKE | Fonction à sortie extensible (XOF) personnalisable | 128 et 256 bits | Séparation de domaine, dérivation de clés | Cumulatif (associatif) |
| KMAC | Code d’authentification de message / fonction pseudo-aléatoire | 128 et 256 bits | Authentification de messages, intégrité | Cumulatif (associatif) |
| TupleHash | Fonction de hachage à longueur variable | 128 et 256 bits | Hachage non ambigu de séquences de chaînes | Un élément de tuple par appel |
| ParallelHash | Fonction de hachage à longueur variable | 128 et 256 bits | Hachage parallèle de très longs messages | Cumulatif (associatif) |
Ce tableau rend visible la singularité de TupleHash : c’est la seule des quatre fonctions dont le comportement en flux diffère fondamentalement des trois autres, ce qui explique pourquoi le NIST ouvre spécifiquement le débat sur ce point dans son appel à commentaires.
Qui est concerné : bibliothèques, éditeurs et chaînes de blocs
Les premiers concernés sont les mainteneurs de bibliothèques cryptographiques. OpenSSL, qui propose déjà KMAC via son architecture de fournisseurs, devra décider s’il implémente l’interface de streaming ou s’il attend la version finale du texte. Les équipes derrière des projets déjà couverts sur ce site, comme la transition imposée par le NIST sur FIPS 140-2, suivent de près ce type de révision parce qu’elle conditionne les futures validations de modules cryptographiques.
Le cas des chaînes de blocs et des bases de données massives
ParallelHash et son mode de streaming intéressent potentiellement les systèmes qui doivent garantir l’intégrité de très gros volumes sans tout recharger en mémoire : sauvegardes différentielles, journaux d’audit en continu, ou structures de preuve pour des bases de données distribuées. Pour l’instant, aucune preuve publique solide n’établit une adoption large de ParallelHash ou TupleHash dans des produits grand public, et il serait hâtif d’annoncer une bascule immédiate. Le NIST a par ailleurs engagé, en parallèle, des travaux sur la cryptographie à seuil, un autre chantier qui mobilise une partie des mêmes équipes de recherche.
Le lien avec la cryptographie post-quantique
Ce qui donne à cette révision un intérêt qui dépasse le cercle des spécialistes du hachage, c’est son lien indirect avec la transition post-quantique. Les deux normes de référence du NIST pour l’échange de clés et la signature résistants aux ordinateurs quantiques, ML-KEM (FIPS 203) et ML-DSA (FIPS 204), s’appuient en interne sur des primitives de la famille Keccak, notamment SHAKE128 et SHAKE256, pour générer des nombres pseudo-aléatoires et encoder certaines structures internes. Toute amélioration apportée à la couche logicielle qui implémente ces fonctions Keccak, y compris une interface de streaming plus efficace pour traiter de gros volumes, profite donc indirectement aux bibliothèques qui mettent en œuvre ML-KEM et ML-DSA.
Ce n’est pas un hasard de calendrier : les équipes qui travaillent sur la cryptographie post-quantique et celles qui maintiennent la famille SHA-3 partagent la même base algorithmique, et une bibliothèque qui optimise son implémentation de Keccak pour cSHAKE ou KMAC optimise mécaniquement une partie du code utilisé par les signatures post-quantiques.
Calendrier : 60 jours de commentaires, et ensuite ?
La fenêtre de commentaires publics court du 8 octobre au 7 décembre 2026. Les retours doivent être envoyés par courriel à l’adresse indiquée dans le document complet (PDF), et porteront probablement en priorité sur la question que le NIST pose lui-même : le comportement différent de TupleHash en mode streaming risque-t-il de prêter à confusion pour les développeurs qui implémentent les quatre fonctions à partir d’une base de code commune ?
Pour donner un ordre de grandeur, le cycle de 2016 avait vu un brouillon publié en août suivi d’une version finale en décembre, soit environ quatre mois. Ce nouveau cycle porte sur un changement d’interface plus structurant qu’une simple clarification rédactionnelle, ce qui laisse penser qu’il pourrait prendre plus de temps avant d’aboutir à un texte définitif.
Nos prédictions pour 2027
- La version finale de SP 800-185 Révision 1 ne devrait pas sortir avant le second trimestre 2027, le temps que le NIST traite les commentaires sur l’ambiguïté de TupleHash et harmonise le texte avec la révision parallèle de FIPS 202.
- FIPS 202 et SP 800-185 seront probablement publiés dans des versions finales rapprochées dans le temps, pour éviter que les deux textes se contredisent sur les mêmes primitives Keccak.
- Les éditeurs de bibliothèques déjà engagés dans la cryptographie post-quantique, notamment ceux qui maintiennent des implémentations de ML-KEM et ML-DSA, seront les premiers à intégrer le mode streaming de cSHAKE et KMAC, parce qu’ils partagent déjà le même code Keccak sous-jacent.
- L’adoption de TupleHash et ParallelHash restera marginale hors de cas d’usage très spécifiques (preuves d’intégrité de gros volumes, structures anti-collision pour bases de données) tant qu’aucun protocole majeur ne les impose explicitement.
- La distinction entre Keccak-256 d’Ethereum et SHA3-256 du NIST continuera de provoquer des erreurs d’implémentation chez les équipes qui font le pont entre blockchain et systèmes conformes aux normes fédérales américaines, faute d’une sensibilisation suffisante à ce piège.
Foire aux questions
SP 800-185 est-il déjà obligatoire ?
Non. Le texte publié le 8 octobre 2026 est un brouillon ouvert aux commentaires publics jusqu’au 7 décembre 2026. La version actuellement en vigueur reste celle de décembre 2016, tant que la révision n’est pas finalisée.
Qu’est-ce qui change concrètement pour les développeurs ?
La révision ajoute une interface optionnelle de traitement en flux, via trois opérations INIT, ABSORB et SQUEEZE, pour traiter des données dont la taille n’est pas connue à l’avance. Les interfaces à appel unique déjà utilisées aujourd’hui restent inchangées et compatibles.
cSHAKE, KMAC, TupleHash et ParallelHash sont-ils liés à SHA-3 ?
Oui, les quatre fonctions dérivent de l’algorithme Keccak, le même bloc de construction que SHA-3, mais elles répondent chacune à un besoin spécifique (séparation de domaine, authentification, hachage de tuples, hachage parallèle) que les quatre fonctions SHA-3 fixes ne couvrent pas directement.
Pourquoi le NIST révise-t-il aussi FIPS 202 ?
Le NIST a annoncé en mars 2025 sa décision de mettre à jour FIPS 202, la norme qui définit SHA-3 et les fonctions SHAKE. Les deux révisions, celle de FIPS 202 et celle de SP 800-185, avancent en parallèle pour que l’ensemble de la famille SHA-3 reste cohérent.
Le Keccak-256 utilisé par Ethereum est-il identique au SHA3-256 du NIST ?
Non. Les deux fonctions partagent la même permutation Keccak-f[1600], mais appliquent des règles de bourrage différentes, ce qui produit des empreintes différentes pour une même entrée. Il faut vérifier explicitement quelle variante une bibliothèque implémente avant de porter du code entre les deux mondes.
Ces fonctions sont-elles liées à la cryptographie post-quantique ?
Indirectement. ML-KEM et ML-DSA, les standards post-quantiques du NIST, utilisent en interne des primitives Keccak comme SHAKE128 et SHAKE256. Les améliorations apportées au code qui implémente la famille SHA-3 profitent donc aussi aux bibliothèques post-quantiques qui partagent cette base algorithmique.
Comment envoyer un commentaire au NIST sur ce brouillon ?
Les commentaires doivent être envoyés par courriel à l’adresse indiquée sur la page officielle du brouillon avant le 7 décembre 2026. Le NIST invite en particulier les retours sur le comportement spécifique de TupleHash en mode streaming.
