Aller au contenu principal

Entropie et Aléatoire en Cryptomonnaie : Pourquoi C'est Important

Chaque clé privée de cryptomonnaie, chaque phrase de récupération et chaque adresse que vous utilisez commence par un nombre aléatoire. La sécurité de l'ensemble de votre portefeuille crypto repose sur une hypothèse : ce nombre était réellement imprévisible. Si le générateur de nombres aléatoires qui a produit votre clé était faible, biaisé ou prévisible, vos fonds peuvent être volés, non pas en cassant la cryptographie, mais en devinant la clé.

Ce guide explique ce que signifie l'entropie dans un contexte cryptographique, comment fonctionnent les générateurs de nombres aléatoires, ce qui s'est historiquement mal passé lorsque l'aléatoire a échoué, et comment vous assurer que votre génération de clés est fiable.

Qu'est-ce que l'entropie ?​

En théorie de l'information, l'entropie mesure le niveau d'incertitude ou d'imprévisibilité d'une donnée. En cryptographie, l'entropie quantifie combien de bits de véritable aléatoire contient une valeur.

Une clé privée de 256 bits devrait avoir 256 bits d'entropie, ce qui signifie qu'un attaquant doit essayer, en moyenne, 2^255 tentatives pour la trouver (la moitié de l'espace de recherche, en moyenne). Si la clé a été générée avec seulement 32 bits d'entropie réelle (à cause d'un RNG défaillant), l'attaquant n'a besoin que d'environ 2^31 essais, soit environ 2 milliards, qu'un ordinateur moderne peut épuiser en quelques minutes.

Mesurer l'entropie​

L'entropie se mesure en bits. L'entropie d'une variable aléatoire X est :

H(X) = -sum(p(x) * log2(p(x))) for all possible values x

Pour un nombre de 256 bits uniformément aléatoire :

  • Chaque bit a une probabilité de 0.5 d'être 0 ou 1.
  • Entropie = 256 bits (maximum pour cette taille).

Pour un générateur biaisé où chaque bit a une probabilité de 0.7 d'être 1 :

  • Entropie par bit = -(0.7 * log2(0.7) + 0.3 * log2(0.3)) = 0.881 bits.
  • Entropie totale pour 256 bits = 225.5 bits (11.9 % de moins que l'idéal).

Même de petits biais se cumulent sur de nombreux bits et peuvent réduire de façon significative le niveau de sécurité effectif.

Entropie dans le contexte BIP-39​

Longueur de la phrase mnémoniqueEntropieNiveau de sécuritéForce brute à 10^12/s
12 mots128 bits128-bit~10^19 ans
15 mots160 bits160-bit~10^28 ans
18 mots192 bits192-bit~10^38 ans
24 mots256 bits256-bit~10^57 ans

Ces chiffres supposent que l'entropie est réellement uniforme. Si le RNG est défaillant, le niveau de sécurité réel peut être drastiquement inférieur.

Types de générateurs de nombres aléatoires​

True Random Number Generators (TRNG)​

Les TRNG échantillonnent des phénomènes physiques intrinsèquement imprévisibles au niveau quantique :

  • Bruit thermique — Fluctuations aléatoires de tension dans les résistances causées par l'agitation thermique des électrons.
  • Bruit de grenaille (shot noise) — Fluctuations aléatoires du courant dues à la nature discrète du flux d'électrons.
  • Désintégration radioactive — Le moment des événements de désintégration individuels est fondamentalement imprévisible.
  • Bruit atmosphérique — Bruit radiofréquence provenant de la foudre et d'autres processus atmosphériques.

Les hardware wallets comme Ledger et Trezor utilisent des TRNG intégrés à la puce. Ils échantillonnent des sources de bruit physique et conditionnent la sortie via un blanchiment et des tests de santé.

Avantages : Véritable aléatoire issu de la physique ; aucun état déterministe à prédire.
Inconvénients : Dépendant du matériel ; peut échouer silencieusement si la source de bruit se dégrade ; débit potentiellement limité.

Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)​

Un CSPRNG est un algorithme déterministe qui produit une sortie indiscernable du vrai aléatoire, à condition d'avoir une graine suffisamment aléatoire :

  • Linux: /dev/urandom (utilise ChaCha20 ou un chiffrement similaire, amorcé par l'entropie matérielle).
  • macOS: /dev/urandom (arc4random, amorcé par l'entropie matérielle).
  • Windows: BCryptGenRandom (fournisseur CNG).
  • Navigateurs web: crypto.getRandomValues() (s'appuie sur le CSPRNG de l'OS).
  • Python: os.urandom() ou module secrets.
  • Node.js: crypto.randomBytes().

Avantages : Rapide ; algorithmes bien étudiés ; disponible sur toutes les plateformes.
Inconvénients : Aussi fort que l'entropie de la graine initiale ; déterministe — si l'état interne est connu, toute sortie future est prévisible.

PRNG non cryptographiques (NE JAMAIS utiliser pour les clés)​

Les fonctions aléatoires des bibliothèques standard de la plupart des langages sont conçues pour la simulation statistique, pas pour la cryptographie :

  • Python: random.random() (Mersenne Twister — déterministe, état récupérable à partir de 624 sorties).
  • JavaScript: Math.random() (xorshift128+ dans V8 — prévisible).
  • C: rand() (générateur congruentiel linéaire — trivialement prévisible).
  • Java: java.util.Random (congruentiel linéaire — prévisible).

Ces générateurs ont une faible entropie, des périodes courtes et un état prévisible. Les utiliser pour générer des clés revient à n'utiliser aucun aléatoire. Ne générez jamais de clés privées ni de phrases de récupération avec ces fonctions.

Défaillances historiques de l'aléatoire​

Le bug Android SecureRandom (2013)​

En août 2013, une faille critique a été découverte dans l'implémentation de SecureRandom sur Android. Le PRNG Java n'était pas correctement amorcé sur certains appareils Android, ce qui a conduit plusieurs applications de wallet Bitcoin à générer des clés privées depuis un état prévisible. Un attaquant a exploité cela pour voler environ 55 BTC. Le bug affectait la génération du nonce de signature ECDSA : réutiliser deux fois le même nonce permet de calculer la clé privée à partir de deux signatures.

Le "Blockchain Bandit" (2019)​

Le chercheur en sécurité Adrian Bednarek a découvert que des wallets avaient été générés avec des clés privées trivialement faibles, comme 1, 2, 3, ou des mots de dictionnaire simplement hachés une fois. Un attaquant vidait systématiquement les fonds de ces adresses depuis des années, accumulant plus de 45 000 ETH. Le bandit énumérait simplement les clés à faible entropie et vérifiait si elles contenaient des fonds.

Exemples de clés vidées :

  • Clé privée 0x0000000000000000000000000000000000000000000000000000000000000001 (le nombre 1)
  • Clés privées dérivées de mots de passe et phrases courantes

La vulnérabilité Milk Sad (2023)​

La commande seed de l'outil libbitcoin-explorer (bx) utilisait Mersenne Twister amorcé avec seulement 32 bits de temps système. Cela signifiait que toutes les clés générées avec cet outil avaient au plus 32 bits d'entropie, soit environ 4,3 milliards de possibilités. Des attaquants ont forcé ces clés par brute force et volé des fonds.

Le bug Debian OpenSSL de clés faibles (2008)​

Un mainteneur Debian a accidentellement supprimé une ligne de code qui fournissait de l'entropie au générateur de nombres aléatoires d'OpenSSL. Pendant deux ans (2006-2008), chaque clé cryptographique générée sur Debian et Ubuntu n'avait que 15 bits d'entropie provenant de l'identifiant de processus, produisant au maximum 32 767 clés uniques. Toutes les clés SSH, certificats SSL et toutes les clés de cryptomonnaie générées pendant cette période sur les systèmes affectés étaient compromises.

Leçons retenues​

  1. Ne faites jamais confiance à une seule source d'entropie sans vérification.
  2. De petites erreurs d'implémentation peuvent réduire catastrophiquement l'entropie.
  3. Les attaquants exploitent activement un aléatoire faible — ce n'est pas théorique.
  4. Du code open-source audité est essentiel pour les opérations critiques liées à l'entropie.

Sources d'entropie en détail​

Pool d'entropie du système d'exploitation​

Les systèmes d'exploitation modernes maintiennent un pool d'entropie alimenté par de multiples sources :

  • Timing des interruptions — Le timing des interruptions matérielles (clavier, souris, disque, réseau) fournit des entrées imprévisibles.
  • Timing des E/S disque — Le timing précis des opérations de lecture/écriture varie selon des facteurs mécaniques et électroniques.
  • RNG matériel — Les CPU modernes (Intel RDRAND, AMD) incluent des générateurs aléatoires intégrés.
  • Entropie au démarrage — Certains systèmes conservent l'entropie entre redémarrages (/var/lib/systemd/random-seed sur Linux).

L'OS mélange ces sources dans un pool d'entropie à l'aide de primitives cryptographiques, puis utilise ce pool pour amorcer son CSPRNG. Sur les noyaux Linux modernes (5.18+), /dev/urandom bloquera jusqu'à ce qu'une entropie suffisante soit collectée au démarrage, puis ne bloquera plus jamais.

Entropie du navigateur (crypto.getRandomValues)​

Quand vous utilisez un outil web comme le générateur de SafeSeed, l'API crypto.getRandomValues() du navigateur est utilisée. Elle s'appuie sur le CSPRNG du système d'exploitation :

  • Chrome : délègue au CSPRNG de l'OS (BoringSSL).
  • Firefox : délègue au CSPRNG de l'OS (NSS).
  • Safari : délègue au CSPRNG de l'OS (CommonCrypto).

Ceci est considéré comme sûr pour la génération de clés, tant que l'OS sous-jacent est sécurisé. La principale inquiétude est d'exécuter cela dans un environnement où le CSPRNG de l'OS pourrait être compromis (par exemple, une machine virtuelle avec des sources d'entropie insuffisantes, ou un système d'exploitation compromis).

Entropie des hardware wallets​

Les hardware wallets utilisent des générateurs de nombres vraiment aléatoires intégrés à la puce :

  • Ledger (Secure Element ST33): Utilise le TRNG de la puce ST33, qui échantillonne du bruit analogique. La sortie passe les tests de santé NIST SP 800-90B avant utilisation.
  • Trezor: Utilise le RNG matériel de la puce STM32. Trezor prend aussi en charge le mélange avec l'entropie fournie par l'utilisateur via des lancers de dés.
  • Coldcard: Utilise le TRNG du secure element ATECC608A plus le RNG matériel du MCU, en mélangeant les deux sources.

Entropie par lancer de dés​

Lancer des dés manuellement est la méthode de génération d'entropie la plus transparente :

  • Un dé équilibré à six faces produit log2(6) = 2.585 bits d'entropie par lancer.
  • 100 lancers produisent environ 258.5 bits d'entropie, suffisant pour une phrase de récupération de 24 mots.
  • L'utilisateur peut vérifier physiquement l'aléatoire (dés équilibrés, lancers équitables, pas de manipulation).

Vérifier l'équité des dés :

  • Utiliser des dés de précision de casino (arêtes vives, non arrondies).
  • Lancer sur une surface dure et plane avec butée.
  • Ne pas "poser" les dés, les laisser rouler librement.
  • Enregistrer chaque résultat immédiatement et dans l'ordre.
Outil SafeSeed

Le générateur de phrase de récupération SafeSeed vous permet de saisir votre propre entropie (comme des résultats de lancers de dés) pour générer une phrase de récupération BIP-39. Cela vous permet de vérifier la source d'aléatoire tout en bénéficiant de l'implémentation correcte de BIP-39 de l'outil. Utilisez l'outil hors ligne pour une sécurité maximale — consultez notre guide de génération de clés hors ligne.

Tester et vérifier l'aléatoire​

Suite de tests statistiques NIST​

NIST SP 800-22 définit une batterie de tests statistiques pour évaluer les générateurs de nombres aléatoires :

  • Test de fréquence — Y a-t-il approximativement autant de 0 que de 1 ?
  • Test de fréquence par blocs — Les sous-blocs de bits sont-ils répartis de manière à peu près uniforme ?
  • Test des runs — Les séquences de bits identiques consécutifs (runs) ont-elles la longueur attendue ?
  • Test du plus long run — Le plus long run est-il dans les limites attendues ?
  • Test de rang matriciel — Les rangs de matrices binaires suivent-ils les distributions attendues ?
  • Test spectral — La TFD de la séquence binaire montre-t-elle les propriétés attendues ?

Ces tests peuvent détecter des biais et des motifs, mais ne peuvent pas prouver qu'un générateur est sécurisé. Ils ne peuvent que détecter des défaillances.

Suite de tests Dieharder​

Une batterie de tests statistiques plus complète qui inclut les tests Diehard d'origine ainsi que des tests supplémentaires. Disponible en logiciel open-source sur Linux.

Vérification pratique pour les utilisateurs​

La plupart des utilisateurs ne peuvent pas exécuter les suites de tests NIST. Étapes de vérification pratiques :

  1. Vérification de la source — L'outil utilise-t-il crypto.getRandomValues(), os.urandom() ou un RNG matériel ? Vérifiez le code source.
  2. Test de génération croisée — Générez plusieurs phrases de récupération et vérifiez qu'elles sont différentes à chaque fois.
  3. Affichage de l'entropie — Certains outils affichent l'entropie brute ; vérifiez qu'elle semble aléatoire (pas de motifs évidents).
  4. Audit open-source — L'outil est-il open-source et a-t-il été audité ?

Mélange de sources d'entropie​

La bonne pratique pour une génération de clés hautement sécurisée consiste à mélanger plusieurs sources d'entropie :

Final Entropy = Hash(Hardware RNG output || OS CSPRNG output || User dice rolls || Timing data)

Le mélange des sources garantit que même si une source est compromise ou biaisée, la sortie finale reste sûre tant qu'au moins une source fournit une entropie suffisante. C'est l'approche utilisée par les hardware wallets et outils de génération de clés bien conçus.

Mélange XOR​

Une méthode de mélange simple est XOR : si vous avez 256 bits de la source A et 256 bits de la source B :

Mixed = A XOR B

Si A ou B est vraiment aléatoire, le résultat est vraiment aléatoire. Si les deux sont biaisées mais indépendantes, le résultat est moins biaisé que chacune.

Mélange par hachage​

Pour mélanger des sources de longueurs ou qualités différentes, hachez-les ensemble :

Mixed = SHA-256(Source_A || Source_B || Source_C)

La fonction de hachage agit comme un extracteur d'entropie, produisant une sortie uniforme quel que soit le format d'entrée.

Entropie dans les configurations multi-signatures​

Les wallets multi-signatures fournissent une forme de redondance d'entropie : même si une clé a été générée avec une entropie faible, l'attaquant doit aussi compromettre les autres clés. Un multisig 2-sur-3 où chaque clé est générée indépendamment offre une sécurité égale à la clé la plus forte, pas à la plus faible.

C'est un argument puissant en faveur des configurations multi-signatures pour le stockage de grande valeur.

FAQ​

Qu'est-ce que l'entropie en cryptomonnaie ?​

L'entropie est la mesure de l'aléatoire ou de l'imprévisibilité des données utilisées pour générer des clés cryptographiques. En cryptomonnaie, la sécurité de vos clés privées et phrases de récupération dépend entièrement d'une entropie suffisante. Une clé de 256 bits doit contenir 256 bits de véritable aléatoire ; si l'entropie est plus faible, la clé devient devinable.

De combien d'entropie ai-je besoin pour un wallet sécurisé ?​

Une phrase de récupération BIP-39 de 12 mots fournit 128 bits d'entropie, et une phrase de 24 mots fournit 256 bits. Les deux sont considérées comme sûres contre les attaques par brute force avec la technologie actuelle. Pour un stockage à long terme de grande valeur, 256 bits (24 mots) sont recommandés afin de fournir une marge de sécurité maximale.

Math.random() est-il sûr pour générer des clés crypto ?​

Absolument pas. Math.random() et les PRNG non cryptographiques similaires (le random de Python, le rand() de C) sont déterministes, prévisibles et ont une faible entropie. Ils ne doivent jamais être utilisés pour la génération de clés cryptographiques. Utilisez toujours crypto.getRandomValues() dans les navigateurs, os.urandom() en Python, ou un générateur aléatoire matériel.

Puis-je générer ma propre entropie en imaginant des nombres aléatoires ?​

Non. Les humains sont notoirement mauvais pour générer des nombres aléatoires. Les études montrent de manière constante que les séquences "aléatoires" choisies par des humains ont bien moins d'entropie qu'elles n'en ont l'air. Utilisez plutôt un processus physique (dés, RNG matériel) ou un RNG logiciel cryptographiquement sûr.

Comment vérifier que le générateur de nombres aléatoires de mon wallet est sécurisé ?​

Vérifiez le code source du wallet (s'il est open-source) pour confirmer qu'il utilise un CSPRNG ou un TRNG matériel. Recherchez des appels à crypto.getRandomValues(), os.urandom() ou des API RNG matérielles. Pour les hardware wallets, consultez la documentation de sécurité du fabricant et les rapports d'audit tiers.

Qu'est-ce que le "blockchain bandit" et qu'enseigne-t-il sur l'entropie ?​

Le "blockchain bandit" est un attaquant qui a systématiquement volé des cryptomonnaies depuis des wallets générés avec des clés privées faibles (comme les nombres 1, 2, 3, ou des clés dérivées de mots de passe simples). Cela a démontré que les attaquants énumèrent activement les clés à faible entropie et vident tous les fonds qu'ils trouvent. Cela souligne l'importance critique d'utiliser une génération aléatoire à forte entropie.

Les générateurs aléatoires des hardware wallets sont-ils fiables ?​

Les TRNG des hardware wallets sont généralement fiables, mais ils représentent un point de confiance unique. Pour une sécurité maximale, vous pouvez mélanger la sortie du RNG matériel avec une entropie fournie par l'utilisateur (lancers de dés). Certains hardware wallets (comme Trezor et Coldcard) prennent en charge ce mélange nativement. Cela garantit que même si le RNG matériel est compromis, la clé résultante reste sécurisée.

Le système d'exploitation (Linux, macOS, Windows) affecte-t-il la sécurité des clés ?​

Oui. La qualité et l'implémentation du CSPRNG de l'OS affectent la sécurité des clés. Les versions modernes de Linux, macOS et Windows fournissent toutes des générateurs de nombres aléatoires cryptographiquement sûrs (/dev/urandom, arc4random, BCryptGenRandom). Cependant, le bug Debian OpenSSL de 2006-2008 a montré que des vulnérabilités au niveau de l'OS peuvent réduire l'entropie de manière catastrophique. Gardez votre OS à jour et utilisez des logiciels bien audités.

Guides associés​