La cryptographie de Bitcoin

Bitcoin tient sur trois piliers : un réseau pair-à-pair, un mécanisme de consensus, et un socle cryptographique. Cet article démonte ce socle. Pas pour t’apprendre à implémenter SHA-256 — pour que tu saches ce qu’il y a dedans, pourquoi c’est ces algorithmes-là et pas d’autres, et ce qui s’effondrerait si l’un d’eux cassait.

On va couvrir cinq briques : la fonction de hash SHA-256, la courbe elliptique secp256k1, le schéma de signature ECDSA, son remplaçant moderne Schnorr (BIP340, activé en 2021), et la chaîne qui transforme une clé publique en adresse Bitcoin. À la fin, tu auras une vue complète de ce que fait Bitcoin chaque fois qu’on signe une transaction.

SHA-256 : le ciment qui lie tout

SHA-256 (Secure Hash Algorithm, 256 bits) est partout dans Bitcoin : il hashe les blocs pour le minage, il identifie les transactions, il sert à dériver les adresses, il signe les messages. Si tu retires SHA-256 de Bitcoin, il ne reste rien.

C’est une fonction qui prend n’importe quelle entrée binaire et produit toujours 256 bits en sortie. Sur les propriétés générales (déterminisme, effet avalanche, irréversibilité), je renvoie au side-quest. Ici on formalise les trois propriétés cryptographiques que Bitcoin attend d’elle, dans leur formulation précise :

1. Résistance à la préimage (one-way) — étant donné un hash h, il est infaisable de trouver un message m tel que SHA256(m) = h. Coût attendu : ≈ 2²⁵⁶ essais. C’est ce qui empêche de remonter d’une adresse à la clé publique tant que tu n’as pas dépensé.
2. Résistance à la seconde préimage — étant donné un message m₁, il est infaisable de trouver un autre message m₂ ≠ m₁ tel que SHA256(m₂) = SHA256(m₁). Coût attendu : ≈ 2²⁵⁶. C’est ce qui empêche un attaquant de substituer une transaction par une autre qui produirait le même identifiant.
3. Résistance aux collisions — il est infaisable de trouver deux messages quelconques m₁ ≠ m₂ tels que SHA256(m₁) = SHA256(m₂). Attention, le coût attendu n’est ici que ≈ 2¹²⁸ (paradoxe des anniversaires), pas 2²⁵⁶. C’est encore largement hors de portée — mais c’est pour ça qu’on parle d’une fonction de hash 256 bits alors qu’on vise un niveau de sécurité de 128 bits.

Tant que personne ne casse SHA-256, Bitcoin tient. Si quelqu’un trouvait demain une collision exploitable, il pourrait fabriquer deux blocs avec le même identifiant, ou deux transactions échangeables, et la chaîne se déchirerait. Plus de 30 ans après la première publication de SHA-1 (1995), et après deux décennies d’analyse intensive de SHA-256, aucune faille pratique n’a été publiée. La fonction est considérée solide jusqu’à l’arrivée d’ordinateurs quantiques tournant l’algorithme de Grover (qui ramènerait la sécurité de 256 à 128 bits — toujours hors de portée, mais on en reparlera dans BTC-A-10 ).

secp256k1 : la courbe qui signe tout

Bitcoin a besoin de signatures numériques : prouver qu’on est bien le propriétaire des fonds qu’on dépense, sans révéler la clé qui le démontre. Pour ça, on utilise la cryptographie à clé publique sur courbe elliptique — ECC en abrégé. Satoshi a choisi une courbe précise : secp256k1, d’équation y² = x³ + 7 dans un corps fini modulo un premier p de 256 bits.

Le choix mérite qu’on s’y arrête. Au moment où Bitcoin naît (2008), le standard cryptographique américain pour les signatures sur courbe elliptique est secp256r1 (aussi appelée P-256 ou prime256v1), une courbe NIST. Satoshi a délibérément choisi secp256k1, une courbe Koblitz moins populaire à l’époque, recommandée par la même SECG mais avec une structure différente.

La multiplication scalaire : le verrou à sens unique

Sur la courbe secp256k1, on définit un point générateur G (coordonnées publiques, fixées par le standard, identiques pour tout le monde). À partir de G, l’opération clé est la multiplication scalaire : pour un entier k, calculer P = k · G, c’est-à-dire additionner G à lui-même k fois (avec des raccourcis algorithmiques quand k est gros, mais c’est l’idée).

Dans le sens k → P, c’est facile. Avec k de 256 bits, ça prend quelques microsecondes sur un téléphone — environ 256 doublements et autant d’additions, soit ~500 opérations sur la courbe.

Dans le sens inverse, c’est infaisable. Étant donné G (public, fixé par le standard) et P (la clé publique observée sur la blockchain), retrouver le k qui vérifie P = k · G est ce qu’on appelle le problème du logarithme discret sur courbe elliptique (ECDLP). Aucun algorithme connu ne fait mieux que ≈ 2¹²⁸ opérations sur secp256k1 — environ le nombre d’opérations qu’un attaquant qui contrôlerait tous les ordinateurs de la planète pendant plusieurs vies de l’univers pourrait effectuer.

C’est cette asymétrie facile/impossible qui fait toute la cryptographie de Bitcoin :

• Ta clé privée k : un entier 256 bits tiré au hasard.
• Ta clé publique P = k · G : le point résultant sur la courbe.

Tu partages P avec le monde entier. Personne ne peut remonter à k. Et tu peux prouver que tu connais k sans le révéler — c’est l’objet du chapitre suivant.

ECDSA : la signature d’origine

ECDSA (Elliptic Curve Digital Signature Algorithm) est le schéma de signature utilisé par Bitcoin depuis 2009. Il prend ta clé privée k, un message m (en pratique : le hash d’une transaction), et produit une signature (r, s) — deux entiers 256 bits — que n’importe qui peut vérifier avec ta clé publique P.

L’algorithme tient en 4 étapes. Sans les détails du calcul modulaire, voilà la logique :

1. Choisir un nonce aléatoire n entre 1 et l’ordre du groupe.
2. Calculer le point R = n · G sur la courbe. On extrait la coordonnée x de R, modulo l’ordre du groupe, ça donne r.
3. Calculer s = n⁻¹ · (hash(m) + r · k) mod q où q est l’ordre du groupe et k ta clé privée.
4. Publier (r, s) avec la transaction.

Vérification : avec P = k · G (ta clé publique) et le message m, n’importe qui peut recalculer R à partir de (r, s) et de P, et vérifier que la coordonnée x correspond à r. Tu prouves que tu connais k sans jamais l’envoyer.

Le talon d’Achille : le nonce

Tout l’édifice ECDSA repose sur une condition catastrophique : le nonce n doit être aléatoire, unique par signature, et secret. Si tu utilises deux fois le même n pour signer deux messages différents avec la même clé k, n’importe qui peut récupérer k à partir des deux signatures. C’est de l’algèbre élémentaire : deux équations à deux inconnues (n et k).

Ce n’est pas théorique. En 2010, Sony a utilisé un nonce constant (la même valeur à chaque signature) dans la signature du firmware de la PlayStation 3. En quelques semaines, le groupe fail0verflow a extrait la clé privée maître de Sony à partir de deux signatures du firmware, et publié le résultat à la conférence 27C3. Plus de mises à jour signées, plus de DRM. Une faute d’implémentation d’un seul paramètre, et toute la chaîne de confiance de la PS3 s’effondre.

Schnorr / BIP340 : la signature moderne (depuis 2021)

ECDSA fait le job, mais il a été choisi en 2008 par élimination : le schéma Schnorr, plus simple et plus puissant, était sous brevet jusqu’en 2008 et son adoption tardive. En novembre 2021, l’activation du Soft-fork Taproot (bloc 709,632) a introduit Schnorr dans Bitcoin via BIP340, à côté d’ECDSA qui continue de fonctionner.

Trois avantages concrets de Schnorr par rapport à ECDSA :

1. Prouvable — la sécurité de Schnorr se démontre formellement à partir de l’ECDLP et du modèle de l’oracle aléatoire. Celle d’ECDSA repose sur des hypothèses supplémentaires, plus fragiles.
2. Linéaire — la signature Schnorr est linéaire en la clé privée, ce qui permet d’agréger plusieurs signatures en une seule. C’est la base de MuSig2 (BIP327, assigné en mars 2022) : N signataires peuvent produire une signature commune indistinguable d’une signature simple. Gain de place dans la blockchain, et vie privée : on ne voit plus que c’est du multi-sig.
3. Déterminisme par construction — BIP340 spécifie un mode déterministe (nonce dérivé du message et de la clé), évitant la classe d’erreurs PS3 by design.

Toutes les transactions Taproot (adresses commençant par bc1p) utilisent Schnorr. ECDSA reste sur les anciennes adresses (1..., 3..., bc1q...) — Bitcoin garde la rétrocompatibilité.

De la clé publique à l’adresse

Tu as une clé publique P = k · G — un point sur secp256k1, soit deux nombres de 256 bits, soit ≈ 130 caractères en hexa. Trop long, et révèle directement la clé publique. Bitcoin hashe la clé publique en une adresse plus courte, qui sert d’identifiant de destination.

Voilà la chaîne pour une adresse SegWit moderne (P2WPKH, celles qui commencent par bc1q…) :

1. P (clé publique, 33 octets compressés)
2. → SHA-256(P) = 32 octets
3. → RIPEMD-160(SHA-256(P)) = 20 octets. Cette double-application a un nom : HASH160. RIPEMD-160 sort 160 bits, ce qui suffit largement pour la résistance aux collisions tout en raccourcissant l’adresse.
4. → encodage bech32 (BIP173 ) avec préfixe bc1q et un checksum auto-correcteur de 6 caractères. Si tu fais une faute de frappe, le wallet la détecte avant d’envoyer.

L’adresse finale ressemble à bc1q9hk...m4xj (42 caractères). Ce que tu partages, c’est ce hash — pas la clé publique. La clé publique elle-même ne devient visible sur la blockchain qu’au moment où tu dépenses depuis cette adresse. C’est une couche de protection supplémentaire : tant que l’adresse n’a jamais dépensé, même un ordinateur quantique cassant ECDLP ne pourrait pas remonter à la clé privée — il n’a pas accès à P, seulement à HASH160(P).

Les adresses Taproot (bc1p…) utilisent un encodage légèrement différent, bech32m (BIP350 ), pour des raisons de correction d’un bug subtil de checksum dans bech32. Même esprit, constante de checksum différente.

Récapitulatif

Quand tu signes une transaction Bitcoin, voilà ce qui se passe en coulisse :

1. Le wallet sérialise la transaction et calcule son hash m (double SHA-256).
2. Avec ta clé privée k, il génère une signature ECDSA ou Schnorr de m — preuve que tu autorises la dépense.
3. La signature est ajoutée à la transaction et diffusée sur le réseau.
4. Chaque nœud vérifie la signature avec ta clé publique P (dérivée de l’adresse source via le script de l’output dépensé). Si OK, la transaction est valide et peut être incluse dans un bloc.

Tout ça en quelques millisecondes, et sans qu’aucun secret quitte ta machine.

Et après

Maintenant qu’on a la cryptographie, on peut regarder l’objet auquel elle s’applique : la transaction Bitcoin, en binaire, octet par octet. Les inputs, les outputs, les scripts, le nLockTime, le poids en vBytes. C’est l’objet de BTC-A-02 — Anatomie d’une transaction Bitcoin (à venir).

Cet article n’est pas un conseil en investissement.