Casser SHA-256 Bitcoin avec Length Extension

Résumé

Une attaque fonctionnelle contre SHA-256 existe. Je l'ai reproduite sur une VM jetable en moins de dix minutes. Elle ne touche pas Bitcoin. L'attaque est le length extension contre la construction Merkle-Damgård, et le double-SHA256 de Bitcoin a été publié comme défense six ans avant le bloc genesis. En dehors de Bitcoin, le correctif canonique est HMAC (RFC 2104). L'algorithme de Grover réduit SHA-256 de 2²⁵⁶ à 2¹²⁸, ce qui reste effectivement infini.

Ce que signifie vraiment « SHA-256 a été cassé »

Toutes les quelques semaines, un nouveau titre annonce que SHA-256 a été cassé. Les forums s'emballent. Un fil Reddit sur r/cryptography (thread 15jpuzg) et une longue discussion sur Hacker News (item 36058754) tournent autour du même malentendu. Il existe une attaque spécifique contre SHA-256 dans un contexte spécifique, et le reste d'internet l'aplatit en « Bitcoin est en danger ».

Ce n'est pas le cas. Je travaille dans l'espace de l'auto-conservation crypto, et chaque fois que ce titre circule, quelqu'un me transfère le fil en demandant si son cold storage est en danger. Son cold storage n'est pas en danger. C'est l'hypothèse sur la manière dont SHA-256 est utilisé ailleurs sur internet qui devrait l'inquiéter.

L'attaque s'appelle une attaque length extension. Elle est réelle. Elle est reproductible en moins de dix minutes sur un ordinateur portable. Bitcoin la neutralise par conception. Toute autre affirmation de « SHA-256 cassé » en 2026 se réduit soit au length extension (que Bitcoin gère), soit à une cryptanalyse académique partielle sur certains tours (qui n'a pas produit d'exploit pratique contre SHA-256 complet), soit à une mauvaise utilisation de SHA-256 pour le stockage de mots de passe, qui est un défaut de conception plutôt qu'un défaut d'algorithme.

La démonstration ci-dessous montre ce que le length extension fait réellement, pourquoi la construction SHA256d de Bitcoin le rend impossible contre la chaîne de hachage Bitcoin, à quoi ressemble la mitigation canonique dans le code non-Bitcoin (HMAC), et le seul cas d'usage où SHA-256 est véritablement non sécurisé : le stockage de mots de passe. À la fin, vous reproduisez l'attaque contre un serveur de démonstration délibérément vulnérable avec un outil Python, puis vous observez la même attaque échouer lorsque le serveur passe à la construction de Bitcoin.

Comment fonctionne Merkle-Damgård

SHA-256 appartient à la famille SHA-2, dont tous les membres partagent la même conception générale appelée construction Merkle-Damgård. La comprendre prend environ une minute, et cette minute rend le length extension évident.

Un hachage Merkle-Damgård prend un long message et le découpe en blocs de taille fixe (64 octets pour SHA-256). Il commence par un état initial fixe (le vecteur d'initialisation), puis exécute une fonction de compression sur chaque bloc qui mélange ce bloc dans l'état. Après le dernier bloc, l'algorithme émet directement l'état comme condensat de hachage.

Cette dernière phrase est tout le problème. Le condensat final du hachage est l'état interne à la fin du calcul. Si vous connaissez Hash(message), vous connaissez l'état interne de la fonction de compression après qu'elle a traité message. Vous pouvez reprendre depuis là.

C'est ce qu'exploite le length extension. Connaissant Hash(secret || message), vous détenez l'état auquel la fonction de compression est arrivée après avoir consommé secret || message. Vous reprenez le calcul depuis cet état, ajoutez les données supplémentaires que vous souhaitez, et produisez un hachage valide. Vous n'apprenez jamais secret.

SHA-3 (Keccak) ne fonctionne pas ainsi. Sa construction en éponge n'émet qu'une troncature de l'état interne, pas l'état lui-même. SHA-512/256, BLAKE2 et BLAKE3 utilisent des astuces de troncature similaires. Ces algorithmes sont immunisés contre le length extension par conception. SHA-256, l'algorithme sur lequel tourne Bitcoin, ne l'est pas.

C'est le fait structurel derrière chaque titre « SHA-256 est cassé ». Voici maintenant l'attaque elle-même en code.

Comment fonctionne le length extension

L'exemple motivant canonique, utilisé dans l'article Wikipedia sur les attaques length extension et reproduit dans chaque manuel de cryptographie depuis 2009, fonctionne ainsi.

Un serveur web signe les requêtes API en calculant SHA-256(secret || params). Il publie la signature avec la requête :

GET /api?user=alice&role=user&sig=a3f1...

Le serveur valide en recalculant SHA-256(secret || "user=alice&role=user") et en le comparant à sig. La construction semble correcte à quiconque n'a pas étudié les règles de rembourrage Merkle-Damgård, c'est-à-dire la plupart des développeurs qui livrent du code en 2026.

L'attaquant capture une paire valide (params, sig). Il devine la longueur en octets de secret (typiquement 16, 32 ou 64, donc il balaye les trois). Il calcule les octets de rembourrage Merkle-Damgård que SHA-256 aurait ajoutés à secret || params avant l'étape de compression finale. Le rembourrage est déterministe (RFC 6234 §4.1). Il initialise alors un nouvel état SHA-256 depuis la sig capturée, car la signature capturée EST l'état interne de la fonction de compression après avoir consommé secret || params || (auto-rembourrage). Depuis cet état il continue le calcul SHA-256, en introduisant &role=admin ou toute extension choisie, et émet le nouvel état comme signature falsifiée.

L'attaquant envoie :

GET /api?user=alice&role=user[octets de rembourrage]&role=admin&sig=<falsifié>

Le serveur recalcule SHA-256(secret || "user=alice&role=user[rembourrage]&role=admin") et arrive exactement à la signature falsifiée, parce que la construction commute avec l'extension de l'attaquant. L'attaquant est désormais admin.

L'exploit public le plus célèbre de ce schéma est la falsification de l'API Flickr en 2009 par Thai Duong et Juliano Rizzo, où la même construction permettait la suppression non autorisée de photos via l'API Flickr. La technique est plus ancienne (Daniel Bleichenbacher en a discuté dans les années 1990) mais le cas Flickr en a fait un incontournable des syllabus de tests de pénétration.

Il faut une paire valide (params, sig) et la longueur en octets du secret. C'est toute la surface d'attaque. SHA-256 n'est pas cassé dans un sens algorithmique. Le développeur a simplement utilisé la mauvaise construction.

Reproduire l'attaque avec hash_extender

Vous pouvez reproduire l'attaque sur votre propre machine en moins de dix minutes. La démonstration complète étape par étape se trouve dans le bloc de données structurées HowTo en haut de cette page. La version résumée, avec les dépôts de sources primaires.

L'outil d'attaque Python eid3t1c/Hash_Extender automatise la falsification length extension pour MD5, SHA-1, SHA-256 et SHA-512. L'implémentation C canonique antérieure par iagox86/hash_extender (la publication originale de 2014) fait le même travail et est l'outil cité dans la plupart des tutoriels length extension depuis 2014. Les deux fonctionnent.

Associez-le à magodo/sha256-length-extension-attack-demo, un serveur Flask délibérément vulnérable qui signe les chaînes de requête avec SHA-256(secret || params). Démarrez le serveur, capturez un token, exécutez hash_extender, soumettez la falsification. Le serveur l'accepte. Vous êtes désormais admin sur un serveur web dont vous n'avez jamais appris le secret.

Puis changez une ligne du serveur de démonstration. Remplacez SHA-256(secret || params) par SHA-256(SHA-256(secret || params)) et relancez l'attaque. La falsification échoue. Le second hachage prend la sortie complète de 256 bits comme entrée, et l'attaquant n'a aucun état interne sur lequel s'appuyer. Cette seule modification reproduit ce que fait Bitcoin sur chaque hachage de bloc, chaque TXID, chaque racine de Merkle.

Une implémentation de référence en Rust de la même attaque figure dans l'article 2026 de Sylvain Kerkour, utile si vous souhaitez suivre la logique de récupération d'état au niveau des octets dans un langage typé. Pour la reproduction la plus simple, les outils Python ci-dessus sont plus rapides.

J'ai exécuté cela de bout en bout la première fois que j'ai travaillé sur cet article. Observer la falsification réussir puis la regarder échouer contre SHA-256(SHA-256(...)) est plus convaincant que n'importe quelle explication de Merkle-Damgård sur la page. Si vous voulez une intuition cryptographique plutôt qu'un vocabulaire cryptographique, c'est l'attaque la moins coûteuse que vous puissiez exécuter.

Pourquoi SHA256d immunise Bitcoin contre le length extension

Bitcoin calcule SHA-256(SHA-256(x)), appelé SHA256d, pour chaque emplacement où un hachage apparaît dans le protocole critique du consensus. Les en-têtes de blocs alimentant la preuve de travail du minage. Les identifiants de transactions. Les racines de Merkle qui agrègent les transactions à l'intérieur d'un bloc. Le hachage de bloc que les mineurs recherchent, un SHA256d qui doit être inférieur à la cible de difficulté.

Ferguson et Schneier ont proposé la construction double-hachage dans Practical Cryptography (2003) comme défense canonique contre les attaques length extension sur SHA-2. L'argument est court. Le SHA-256 externe est calculé sur la sortie complète de 256 bits du SHA-256 interne. Un attaquant qui connaît SHA256d(secret || params) ne connaît pas l'état interne de la fonction de compression externe de façon exploitable. Pour récupérer cet état, il devrait inverser le SHA-256 externe, ce qui est une attaque de préimage à environ 2²⁵⁶ opérations. C'est la garantie de sécurité.

Une réponse fréquemment citée sur crypto.stackexchange.com retrace la justification depuis Tahoe-LAFS (qui a adopté SHA256d en 2006) jusqu'à l'adoption par Bitcoin en 2009. Le livre blanc dit simplement « SHA-256 » et la liste de diffusion de cryptographie est silencieuse sur le choix de la construction, donc nous ne pouvons pas prouver que Satoshi a explicitement choisi SHA256d pour neutraliser le length extension. Nous savons que Ferguson-Schneier avait publié la construction six ans auparavant, que Tahoe-LAFS l'utilisait déjà pour les hachages de capacités du système de fichiers pour cette raison exacte, et que Bitcoin a été livré avec SHA256d dès le premier jour. Tirez vos propres conclusions. Le fait technique reste valable dans tous les cas : la chaîne de hachage de Bitcoin est immune au length extension, et l'attaque qui produit les titres « SHA-256 est cassé » ne s'applique à aucune couche du protocole Bitcoin.

HMAC, le correctif pour tous les autres

La plupart des développeurs de logiciels n'écriront jamais SHA256d. Ils écriront HMAC.

HMAC (RFC 2104) est l'enveloppe universelle immune au length extension pour tout hachage Merkle-Damgård. Étant donné une fonction de hachage H (SHA-256, SHA-1, MD5, HMAC fonctionne pour tous), HMAC est défini comme :

HMAC(key, message) = H( (key ⊕ opad) || H( (key ⊕ ipad) || message ) )

opad et ipad sont des motifs d'octets fixes (0x5c5c5c... et 0x363636...). Le hachage interne absorbe le message. Le hachage externe hache la sortie interne avec une dérivée de clé différente.

La construction ressemble à SHA256d mais est plus flexible. HMAC prend une clé comme paramètre de premier ordre, supporte tout hachage sous-jacent, et s'intègre proprement avec les piles de fonctions de dérivation de clés. C'est la norme IETF depuis que RFC 2104 a été publié en 1997, et chaque bibliothèque cryptographique traite HMAC-SHA256 comme une primitive.

Les deux endroits où vous le rencontrez le plus souvent en production sont TLS 1.3, qui utilise HMAC-SHA256 à l'intérieur de son calendrier de clés HKDF (RFC 8446 §7.1), et les tokens JWT avec l'algorithme HS256, qui sont signés HMAC-SHA256(secret, header.payload). AWS SigV4 et WebAuthn s'appuient tous deux sur la même primitive pour la même raison.

Si votre code calcule hash(secret + message) n'importe où en dehors de Bitcoin, remplacez-le par HMAC. Le coût est une invocation de hachage supplémentaire. Le gain de sécurité est une immunité totale au length extension.

Pourquoi Bitcoin est resté sur SHA-256 et non SHA-3

SHA-3 (Keccak), standardisé par le NIST en 2015 (FIPS-202), est construit sur une conception fondamentalement différente appelée construction en éponge, qui est immune au length extension par construction. Pas besoin de double-hachage. Pas besoin d'enveloppe HMAC. Les hachages SHA-3 peuvent être utilisés comme MACs directement (parfois appelés KMAC) et restent sécurisés.

Bitcoin fonctionne toujours sur SHA-256 en 2026 pour des raisons qui relèvent davantage de la dépendance au chemin que de considérations cryptographiques. Changer l'algorithme de hachage nécessite un hard fork. Chaque nœud complet, chaque mineur, chaque portefeuille, chaque explorateur de blocs, chaque BIP, chaque schéma de signature touche SHA-256 quelque part. Une migration coordonnée est techniquement possible mais politiquement catastrophique. Des dizaines de milliards de dollars de matériel ASIC existent spécifiquement pour calculer SHA-256 au débit maximum, et remplacer l'algorithme rend toute la base de minage obsolète du jour au lendemain. SHA-256 est également plus rapide que SHA-3 sur les CPU modernes et dramatiquement plus rapide sur les ASICs, ce qui importe pour la vérification sur chaque nœud complet.

L'argument cryptographique pour rester en place est plus simple. SHA256d résout déjà la seule faiblesse structurelle de SHA-256 qui compte dans le modèle de menace de Bitcoin. Il n'y a aucun problème existant que la migration résoudrait. SHA-3 aurait été un choix défendable en 2009. Le coût de la migration en 2026 dépasse largement l'avantage.

Quantique, Grover et SHA-256

Les ordinateurs quantiques ne cassent pas SHA-256.

L'algorithme quantique pertinent contre une fonction de hachage est l'algorithme de Grover, qui apporte une accélération quadratique sur la recherche non structurée. Pour SHA-256, cela réduit la résistance aux préimages de 2²⁵⁶ opérations classiques à 2¹²⁸ opérations quantiques. 2¹²⁸ est encore effectivement infini, bien au-delà de tout matériel quantique plausible prévu pour les prochaines décennies.

L'algorithme de Shor est celui à craindre réellement, et il ne touche pas SHA-256. Shor apporte une accélération exponentielle sur le problème du logarithme discret, ce qui casse ECDSA (le schéma de signature de Bitcoin) en temps polynomial sur un ordinateur quantique suffisamment grand. Le risque quantique de Bitcoin réside dans les signatures, pas dans le hachage.

Le tableau quantique 2026 pour Bitcoin spécifiquement, incluant BIP-360, BIP-361 et le cadre de migration PACTs, fait l'objet de deux articles distincts sur ce site. Voir BIP-360/361 : Bitcoin résistant aux quantiques et Informatique quantique, Bitcoin et l'annonce de Google en 2026. La version courte : SHA-256 va bien. ECDSA nécessite une migration. Les délais pour les deux sont séparés de décennies.

La menace « harvest-now-decrypt-later » s'applique uniquement aux signatures ECDSA de Bitcoin. Elle ne s'applique pas à SHA-256 de façon significative, car une primitive résistante à 2¹²⁸ est non récupérable, que l'on moissonne ou non.

Où SHA-256 échoue sur les mots de passe

Le seul contexte où « SHA-256 n'est pas sécurisé » est justifié est le stockage des mots de passe.

Cela n'a rien à voir avec le length extension. SHA-256 est trop rapide. Un GPU grand public moderne calcule des milliards de hachages SHA-256 par seconde, et Hashcat publie les benchmarks ouvertement. Pour un mot de passe haché SHA-256 non salé de moins d'environ 15 caractères aléatoires, un attaquant disposant d'un seul GPU grand public force tout l'espace en quelques heures.

Le stockage des mots de passe nécessite une fonction de hachage délibérément lente et gourmande en mémoire, de sorte qu'un GPU n'ait aucun avantage sur un CPU. Utilisez Argon2id (RFC 9106, recommandé par OWASP en 2026), ou scrypt ou bcrypt si vous êtes bloqué sur une pile plus ancienne.

Si vous trouvez SHA-256 utilisé pour le stockage de mots de passe dans du code 2026, le correctif consiste à migrer toute la base d'utilisateurs (typiquement en rehachant à la prochaine connexion). N'ajoutez pas de défenses contre le length extension. Le vrai problème est la vitesse de brute force, et le length extension n'a aucun rapport avec ça.

Où SHA-256 vit à l'intérieur de Bitcoin

Pour Bitcoin spécifiquement, SHA-256 (presque toujours comme SHA256d) apparaît dans plusieurs rôles distincts :

Chacun de ces rôles représenterait une perte catastrophique d'intégrité si SHA-256 était cassé. Aucun d'eux n'est en danger pratique en 2026. Les attaques pratiques connues (length extension, collisions partielles sur 31 des 64 tours, brute force GPU rapide sur de petits espaces d'entrée) n'atteignent pas l'algorithme SHA-256 complet dans aucun rôle qui compte dans Bitcoin.

La comparaison pertinente est SHA-1, qui a été cassé en pratique par l'attaque de collision SHAttered de Google en 2017 contre SHA-1 complet. SHA-256 n'est pas dans cet état et n'a aucune trajectoire cryptanalytique à court terme dans cette direction.

Le verdict 2026, par cas d'usage

La chaîne tient. Chaque utilisation critique du consensus de SHA-256 dans Bitcoin passe par SHA256d, que j'ai déjà montré être immune au length extension. Il n'existe aucune attaque pratique de préimage sur SHA-256 complet en 2026, aucune attaque pratique de collision, et rien à l'horizon cryptanalytique qui s'en approche. Le minage Bitcoin, les TXIDs, les racines de Merkle, les adresses P2PKH et P2WPKH, la dérivation de graine BIP-39 via PBKDF2-HMAC-SHA512 : tout est sécurisé.

En dehors de Bitcoin, partout où SHA-256 est derrière une enveloppe HMAC (signature d'enregistrement TLS 1.3, JWT-HS256, AWS SigV4), il est également sécurisé. SHA-256 brut utilisé pour l'adressage de contenu ou comme pré-hachage pour les signatures numériques ou les vérifications d'intégrité d'archives à long terme convient parfaitement, parce que le length extension est non pertinent quand il n'y a pas de secret ni de MAC.

Deux schémas continuent d'échouer en 2026 et vous devriez les corriger dès que vous les voyez. Les MACs maison de la forme Hash(secret || message) sont trivialement falsifiés par length extension. Passez à HMAC. Le stockage de mots de passe SHA-256 brut, salé ou non, est forcé par un seul GPU parce que SHA-256 est trop rapide. Passez à Argon2id.

Les deux échecs sont des échecs de construction, pas des échecs d'algorithme. SHA-256 lui-même fait toujours le travail qu'il fait depuis 2001.

Pour aller plus loin

Cet article fait partie d'un petit groupe sur btc2h.com qui examine les primitives cryptographiques dont Bitcoin dépend réellement, et ce que la recherche actuelle signifie pour chacune d'elles. Trois lectures complémentaires :

• BIP-360 / BIP-361 : Le plan de migration Bitcoin résistant aux quantiques couvre le tableau quantique côté signatures, là où réside le vrai risque à long terme.
• Informatique quantique, Bitcoin et l'annonce de Google en 2026 met en contexte le cycle d'actualités sur le matériel quantique 2026.
• Tutoriel btcrecover 2026 montre pourquoi la vitesse de brute force GPU de SHA-256 est la bonne réponse pour la récupération de mots de passe de portefeuilles et la mauvaise pour le stockage de mots de passe.

Bibliographie de sources primaires pour cet article (vérifiées accessibles au 2026-05-12 sauf mention contraire) :

• Wikipedia, Attaque par extension de longueur
• Wikipedia, SHA-2
• RFC 6234, Algorithmes de hachage sécurisés américains (spécification de rembourrage SHA-256)
• RFC 2104, HMAC Keyed-Hashing for Message Authentication
• crypto.stackexchange.com Q779, Pourquoi Bitcoin utilise-t-il le double SHA-256 ?
• Reddit r/cryptography, fil length extension SHA-256
• Hacker News fil 36058754
• arXiv 2406.20072, cryptanalyse SHA-256 sur tours partiels (affirmation : résultats sur tours partiels, aucune attaque pratique sur tours complets. Vérifier contre l'abstract de l'article avant de citer les bornes numériques.)
• Kerkour, Breaking SHA-2 length extension attacks in practice with Rust
• eid3t1c/Hash_Extender (outil d'attaque Python)
• magodo/sha256-length-extension-attack-demo (serveur Flask vulnérable)
• sjlombardo length-extension gist (2012)
• Ferguson & Schneier, Practical Cryptography (2003), la publication canonique de SHA256d

Avertissement

Cet article est un contenu éducatif destiné aux détenteurs et développeurs Bitcoin. Il ne constitue pas un conseil juridique, financier ou d'ingénierie cryptographique. Les déploiements cryptographiques réels nécessitent une revue formelle par des spécialistes qualifiés. N'implémentez pas de code critique pour la sécurité à partir d'un article de blog. Pour les systèmes en production gérant des secrets, utilisez des bibliothèques éprouvées (libsodium, OpenSSL, Bouncy Castle) plutôt que de créer vos propres primitives. Pour les questions juridiques ou de conformité concernant l'agilité cryptographique sous FINMA, GDPR ou NIS2, consultez un conseil qualifié.