basu_← Back to the universe
FIELD NOTES

Hashing goes brrr : Merkle, Winternitz et le vrai coût d’un hash

Comprendre les signatures fondées sur des chaînes de hash et pourquoi l’usage unique est littéral.

Cette note propose une lecture théorique du challenge Hashing goes brrr, classé en cryptographie sur Hackropole. Ce n’est pas une solution officielle ni une copie de write-up : l’objectif est de comprendre le mécanisme intellectuel que ce type d’épreuve cherche à faire manipuler.

L’idée en une image

Une chaîne de hachage est un escalier à sens unique. On peut descendre en recalculant le hash, mais on ne sait pas remonter vers une valeur précédente.

Le niveau « hardcore » ne vient généralement pas d’une formule isolée. Il vient de la nécessité de reconnaître quelle structure est exposée, puis d’écarter tout ce qui n’influence pas réellement le secret.

Le modèle mathématique

Une signature de type Winternitz révèle des positions dans plusieurs chaînes H^i(x). Réutiliser une clé peut révéler deux positions différentes ; la plus ancienne permet parfois d’avancer jusqu’à la plus récente et de signer des chiffres supplémentaires.

La première discipline consiste à écrire les objets avec leur domaine : entiers, classes modulo un nombre, vecteurs sur un corps fini ou octets. Une grande partie des bugs de raisonnement vient d’une opération effectuée dans le mauvais espace.

Ce qu’il faut repérer

  • De nombreuses valeurs obtenues par itérations successives d’un hash
  • Une clé dite one-time utilisée pour plusieurs messages
  • Un arbre de Merkle qui authentifie des clés publiques éphémères

Ces indices ne prouvent pas encore une attaque. Ils servent à former une hypothèse testable : « si ce modèle est le bon, quelle valeur intermédiaire devrais-je pouvoir prédire ? »

Démarche d’analyse

  1. Encoder le message exactement comme le schéma le fait.
  2. Repérer pour chaque chaîne la position déjà révélée.
  3. Comparer les signatures composante par composante.
  4. Respecter checksum et ordre des feuilles.

À chaque étape, conserver un petit test connu. Un script qui produit un résultat plausible mais non vérifié est plus dangereux qu’une équation incomplète : il donne l’impression d’avancer.

Pourquoi le challenge devient difficile

Une épreuve avancée superpose souvent plusieurs couches : parsing, encodage, protocole et primitive. La bonne stratégie consiste à construire des invariants. Une taille doit rester constante, un point doit satisfaire son équation, une signature doit se vérifier, un état prédit doit reproduire plusieurs sorties jamais utilisées pendant l’analyse.

On peut formaliser ce réflexe ainsi :

  1. Observer une relation stable.
  2. Modéliser cette relation avec le moins d’hypothèses possible.
  3. Prédire une nouvelle valeur.
  4. Valider la prédiction sur des données indépendantes.

Fausses pistes classiques

  • Chercher une collision générique.
  • Oublier que le checksum limite les falsifications naïves.
  • Mélanger octets, hexadécimal et entiers.

La difficulté utile d’un challenge n’est pas de lancer tous les outils disponibles. Elle est de savoir quelle propriété chaque outil teste et ce qu’un échec permet réellement de conclure.

Ce que l’architecte sécurité doit en retenir

La gestion d’état est aussi importante que le hash : une clé à usage unique doit réellement n’être utilisée qu’une fois.

La crypto échoue rarement parce que l’algorithme central est totalement inconnu. Elle échoue aux frontières : génération d’aléa, réutilisation d’état, encodage, validation, gestion des erreurs et composition avec le protocole.

Pour aller plus loin

Reprendre le challenge en construisant d’abord un modèle miniature avec de petits paramètres. Une fois l’intuition vérifiée, remplacer progressivement les jouets par les vraies tailles. C’est plus lent pendant dix minutes et beaucoup plus rapide pendant les trois heures suivantes.

← All notes