En cryptographie, l’entropie décrit l’incertitude qui reste à un attaquant cherchant à deviner une valeur secrète. Pour un portefeuille Bitcoin, elle compte dès la création de la base de ses clés. Il ne s’agit pas de savoir si les caractères paraissent compliqués, mais combien de résultats étaient réellement possibles, avec quelles probabilités, et ce que l’attaquant connaît du procédé.
Imaginez un secret créé à partir de la date et de l’heure d’ouverture d’un portefeuille. Une fois encodé, il peut ressembler à un long mélange de caractères. Mais si l’attaquant connaît l’heure approximative et la méthode, il n’a peut-être qu’un petit ensemble de possibilités à essayer. Allonger l’écriture ne lui complique pas forcément la tâche. Voilà pourquoi le RFC 4086 distingue l’imprévisibilité de la simple apparence du hasard. Un coup d’œil à une clé ne permet pas d’évaluer son entropie ; il faut savoir comment elle a été créée. [3]
Un bit est une unité élémentaire de données, dont la valeur est 0 ou 1. Le nombre de bits ne dit pas, à lui seul, combien d’incertitude reste pour un attaquant. Lorsqu’un portefeuille crée une Seed Phrase selon BIP39, il lui faut d’abord une entrée aléatoire. Il la transforme ensuite en mots. Pour 12 mots, il s’agit de 128 bits d’entrée et de 4 bits de somme de contrôle ; pour 24 mots, de 256 bits d’entrée et de 8 bits de contrôle. La somme de contrôle aide à repérer certaines erreurs de transcription, mais n’ajoute pas d’entropie : elle est calculée à partir de l’entrée existante. Une liste plus longue ne corrige donc pas un mauvais procédé de génération aléatoire. La manière dont la sauvegarde a été créée compte, pas seulement son nombre de mots. [4]
Un portefeuille n’a pas besoin d’effectuer une nouvelle mesure physique pour chaque octet, c’est-à-dire chaque groupe de 8 bits. Il peut utiliser un générateur cryptographique appelé DRBG : un algorithme qui produit d’autres valeurs à partir d’un état initial secret. Bien conçu et bien utilisé, il rend les sorties difficiles à prédire sans connaître cet état. Pourtant, l’algorithme est déterministe : le même état complet et les mêmes entrées donnent la même suite. Produire davantage d’octets ne crée donc pas automatiquement davantage d’entropie physique nouvelle. La qualité de l’entrée initiale et la protection de l’état interne sont toutes deux essentielles. [2]
Une fonction de hachage calcule une empreinte de longueur fixe à partir des données ; cette empreinte peut paraître aléatoire. Mais quiconque connaît l’entrée peut calculer le même résultat. Des entrées entièrement connues ne deviennent pas secrètes ainsi. Le terme technique conditioning désigne un traitement qui peut réduire les biais et concentrer l’incertitude déjà disponible. Il ne crée pas un secret à partir de rien. On ne peut pas non plus additionner automatiquement l’entropie de plusieurs sources : elles peuvent être liées et fournir la même information. [1] [3]
Une source de bruit électronique peut tomber en panne ou changer de comportement avec son environnement. Le NIST SP 800-90B exige donc des contrôles du bruit brut au démarrage et pendant le fonctionnement, avant son traitement. Ces contrôles cherchent des signes de défaillance ; ils ne prouvent pas que chaque sortie est sûre. Le développeur doit comprendre la source, ses limites et ses dépendances possibles. Une défaillance détectée doit être signalée à l’application qui utilise les données. En cas de panne persistante, la source doit cesser de produire des sorties. Une puce présentée comme un générateur aléatoire ne suffit pas à elle seule. [1]
Si un attaquant obtient l’état interne d’un DRBG, il peut, selon sa conception, prévoir les sorties suivantes. Pour rétablir l’imprévisibilité, il faut assez de nouvelles données que l’attaquant ne connaît pas ; cet apport d’entropie s’appelle reseeding. Continuer simplement les calculs ou ajouter une heure connue ne garantit pas cette protection. Il faut aussi distinguer la réparation du générateur de la sécurité des fonds existants : remettre le générateur en état n’invalide pas une clé déjà divulguée. [2]
Un test statistique peut par exemple révéler des répétitions suspectes. Il ne peut toutefois pas déterminer avec certitude si un attaquant connaît l’entrée secrète ou une méthode de prédiction de la sortie. Le NIST SP 800-22 souligne expressément cette limite. Les tests sont une partie utile de l’évaluation, pas un remplacement de l’analyse du générateur entier. Un fichier rempli de nombres apparemment aléatoires ne prouve donc pas, à lui seul, qu’un portefeuille est sûr. [5]
Un débutant n’a pas besoin de calculer à la main l’entropie de son portefeuille. Il est plus utile de chercher un procédé documenté : d’où vient le hasard, comment est-il traité, comment les erreurs sont-elles gérées et comment les secrets sont-ils protégés ? Le NIST SP 800-90C traite précisément de l’association des sources d’entropie et d’un DRBG en un générateur complet. Mais citer une norme ou une puce connue ne prouve pas qu’une version précise du portefeuille l’utilise correctement. Ce qui compte, ce sont les propriétés vérifiées de l’implémentation réelle. [1] [6]
Pour une vision complète, lisez aussi Entropy Bit, CSPRNG, Dice Roll Entropy, Private Key. Cette entrée est également citée par BIP85, Dice Roll Entropy, Entropy Bit, Brute Force Search Space.