Aller au contenu
Financial Context Wiki

Fonctions de hachage cryptographiques

Un guide axé sur la vérification des fonctions de hachage cryptographiques, couvrant les propriétés de sécurité, l'encodage en octets, SHA-2, SHA-3, Keccak, les usages dans les blockchains et les risques de mise en œuvre.

Mis à jour

À des fins éducatives uniquement ; ceci ne constitue ni un conseil en investissement ni un conseil de mise en œuvre cryptographique. Une empreinte concordante ne prouve pas à elle seule l’authenticité, la propriété, l’autorisation, la finalité ou la disponibilité des données.

Réponse directe

Une fonction de hachage cryptographique associe de manière déterministe un message représenté sous forme d’octets à une empreinte dont la longueur de sortie est définie. Pour une fonction de hachage à longueur fixe de n bits, la relation fondamentale est :

h = H(m), where h is in {0,1}^n

Les mêmes octets et le même algorithme produisent la même empreinte. La modification d’un seul bit en entrée doit changer de manière imprévisible de nombreux bits en sortie, mais cet effet d’avalanche ne constitue pas la définition de la sécurité. Les principaux objectifs de sécurité sont la résistance à la préimage (étant donnée une empreinte, il est impossible en pratique de trouver une entrée qui la produit), la résistance à la seconde préimage (étant donnée une entrée, il est impossible en pratique d’en trouver une autre ayant la même empreinte) et la résistance aux collisions (il est impossible en pratique de trouver deux entrées distinctes ayant la même empreinte).

Le hachage n’est pas du chiffrement : il n’existe aucune clé de déchiffrement ni aucune garantie que l’entrée puisse être retrouvée. Comme une infinité de messages possibles est projetée dans un espace de sortie fini, des collisions existent nécessairement ; la sécurité signifie qu’il est infaisable, sur le plan informatique, d’en trouver une exploitable avec l’algorithme et la longueur de sortie choisis.

Une empreinte n’apporte pas non plus d’authenticité à elle seule. Recalculer le hachage d’un fichier ne détecte une différence que si l’empreinte attendue et l’algorithme ont été obtenus par un canal de confiance. Les protocoles renforcent les garanties en associant les hachages à des signatures, des codes d’authentification de message, des structures de données authentifiées, des règles de consensus ou une preuve de travail.

Fonctionnement

  1. Définir les octets exacts. L’encodage du texte, la casse, les espaces, l’ordre des champs, la représentation des entiers, les préfixes de longueur et la sérialisation influent tous sur m. Un protocole doit préciser un encodage canonique et lier le hachage à un algorithme, une version, un réseau et un usage.
  2. Exécuter la construction spécifiée. SHA-256 prétraite un message de longueur bornée, le divise en blocs et met à jour de manière itérative un état interne. SHA3-256 utilise une construction en éponge fondée sur KECCAK. Les deux produisent des empreintes de 256 bits, mais ce sont des fonctions différentes et leurs résultats ne sont pas interchangeables.
  3. Interpréter la sécurité selon la propriété requise. Pour un hachage idéal de n bits, une recherche générique de préimage exige environ 2^n évaluations, tandis qu’une recherche générique de collision en exige environ 2^(n/2) en raison du paradoxe des anniversaires. La longueur de sortie ne suffit pas si l’algorithme est compromis, si l’empreinte est tronquée ou si le protocole environnant est défaillant.
  4. Construire le protocole autour de l’empreinte. Un système de signature numérique peut signer l’empreinte d’un message ; HMAC ajoute une clé secrète pour l’authentification des messages ; un arbre de Merkle engage un grand nombre de feuilles dans une seule racine ; et la preuve de travail hache de façon répétée des en-têtes de bloc candidats jusqu’à ce qu’une empreinte satisfasse une cible. Ces constructions offrent des garanties différentes.
  5. Utiliser la fonction exacte de la chaîne. Les en-têtes de bloc et les nœuds de Merkle de Bitcoin utilisent un double SHA-256 avec un ordre des octets défini. L’exécution d’Ethereum utilise Keccak-256, issu de la conception KECCAK antérieure à la normalisation, et non SHA3-256 normalisé. Une désignation telle que « hachage de 256 bits » ne suffit donc pas pour effectuer une vérification.
  6. Vérifier le contexte avant d’en tirer une signification. Contrôlez la source de l’empreinte attendue, l’identifiant de l’algorithme, l’encodage des octets, le domaine ou la chaîne, la référence de bloc et d’état, le statut de confirmation et toute troncature. Un calcul correct effectué dans le mauvais contexte reste une vérification échouée.

Exemples détaillés

  • Une modification minime de l’entrée. Le SHA-256 des cinq octets UTF-8 de hello est 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Remplacer le premier octet par le H majuscule donne 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Les empreintes différentes ne révèlent pas quel octet a changé.
  • La robustesse de sécurité n’est pas toujours égale à la longueur de l’empreinte. Un hachage idéal de 256 bits offre environ 2^256 opérations de résistance à la préimage, mais 2^128 opérations de résistance aux collisions. Cette distinction compte lorsqu’un protocole dépend de la résistance aux collisions, comme c’est souvent le cas dans les processus de signature numérique.
  • Une preuve de Merkle authentifie l’inclusion par rapport à une racine donnée. Un vérificateur hache la feuille encodée avec chaque nœud frère fourni, dans l’ordre spécifié, jusqu’à reconstruire la racine engagée. Une correspondance ne prouve ni que la racine est finalisée, ni que les données de la feuille sont vraies, ni que les données omises sont disponibles.
  • La preuve de travail ajoute une règle de cible. Bitcoin ne valide un en-tête candidat que lorsque sa valeur double-SHA-256, interprétée selon les règles de consensus, est inférieure ou égale à la cible encodée. L’empreinte ne devient pas plus résistante aux collisions parce que les mineurs ont fourni davantage de travail.

Risques

  • Utiliser un algorithme obsolète ou inadapté, notamment SHA-1 lorsqu’une résistance aux collisions est requise.
  • Considérer SHA3-256, Keccak-256, SHA-256, le double SHA-256 et leurs variantes tronquées différemment comme interchangeables.
  • Hacher le texte affiché au lieu des octets canoniques, ou négliger la normalisation Unicode, les espaces, le boutisme, l’ordre des champs et l’encodage des longueurs.
  • Télécharger un fichier et son empreinte attendue depuis le même emplacement compromis, ce qui n’apporte aucune vérification indépendante de l’intégrité.
  • Utiliser directement un hachage polyvalent et rapide pour stocker des mots de passe, au lieu d’un système de hachage de mots de passe salé, conçu à cet effet et doté d’un facteur de travail approprié.
  • Utiliser H(secret || message) comme code d’authentification artisanal ; certaines constructions de hachage itératives permettent des attaques par extension de longueur, tandis que HMAC est conçu pour l’authentification avec clé.
  • Tronquer les empreintes sans calculer la résistance aux collisions et aux préimages qui en résulte à l’échelle et selon le modèle de menace du protocole.
  • Réutiliser un encodage dans plusieurs protocoles sans séparation de domaines, permettant à une empreinte valide dans un contexte d’être interprétée dans un autre.
  • Supposer qu’un hachage de transaction prouve la confirmation, la finalité, la réussite de l’exécution, la propriété ou l’absence de réorganisation de la chaîne.
  • Supposer qu’un hachage de contenu rend les données référencées récupérables ; un engagement peut rester valide alors même que toutes les copies disponibles ont disparu.
  • Comparer les chaînes affichées par des explorateurs sans vérifier l’ordre des octets, les règles de préfixe, la sérialisation ou si l’interface affiche différemment un identifiant interne.
  • Mettre en œuvre des primitives cryptographiques sans vecteurs de test normalisés, bibliothèques maintenues, examen indépendant et procédures de mise à niveau.

Idées reçues courantes

  • Un hachage est une donnée chiffrée. Le chiffrement est réversible avec la clé appropriée ; un hachage cryptographique est une empreinte à sens unique sans opération de déchiffrement.
  • Deux entrées différentes ne peuvent jamais partager la même empreinte. Les collisions existent nécessairement pour une sortie de longueur fixe. Une conception sûre les rend infaisables à trouver et à exploiter.
  • Une empreinte de 256 bits fournit toujours 256 bits de sécurité. La résistance générique aux collisions est d’environ 128 bits pour un hachage idéal de 256 bits, et les choix du protocole peuvent encore la réduire.
  • Des hachages identiques prouvent qui a créé le message. Un hachage seul ne contient aucun secret et n’authentifie aucun expéditeur ; utilisez une signature ou un MAC adapté lorsque l’origine importe.
  • Keccak-256 et SHA3-256 sont deux noms de la même fonction. Leur conception est étroitement apparentée, mais leurs paramètres de normalisation diffèrent et ils produisent des empreintes différentes.
  • Le hachage d’une transaction sur la chaîne prouve son règlement. Il identifie les données encodées de la transaction ; l’inclusion dans la chaîne, l’état de l’exécution, les confirmations et la finalité sont des faits distincts.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...