Un Deterministic RNG est un générateur de nombres pseudoaléatoires : il calcule des valeurs selon une procédure fixe au lieu de mesurer un nouvel événement physique aléatoire pour chacune. Il part d’une entrée appelée seed et conserve un état interne, les données nécessaires au calcul suivant. Répéter toute la procédure avec les mêmes entrées reproduit les résultats, ce qui facilite les tests. Un générateur cryptographique sûr exige aussi une conception adaptée et assez d’entropie : de l’incertitude sur l’entrée du point de vue de l’attaquant.
Imaginez que l’on mette un calcul en pause et que l’on sauvegarde sa mémoire. Le reprendre au même point avec les mêmes entrées suivantes peut reproduire la suite. NIST SP 800-90A décrit ces générateurs sous le nom de DRBG. L’algorithme, les paramètres et l’ordre des demandes comptent. L’ajout d’entropie fraîche, appelé reseeding, modifie l’état. Un seed identique ne garantit donc pas la même sortie entre programmes différents. [1]
Même un simple programme de simulation peut produire des nombres d’apparence aléatoire. Cela ne suffit pas à protéger un portefeuille. RFC 4086 avertit qu’un attaquant peut prévoir certaines de ces suites malgré leur réussite aux tests statistiques. Un générateur cryptographiquement robuste doit rester imprévisible en pratique lorsqu’une partie de sa sortie est connue. Sa conception, la qualité et le secret des données initiales comptent davantage que le seul mot « déterministe ». [2]
Pour retrouver un bug, il est utile de reproduire exactement la même situation. La fonction randombytes_buf_deterministic() de libsodium renvoie donc la même suite pour le même seed. Le développeur peut publier le résultat attendu afin que d’autres le vérifient. C’est précisément pourquoi un seed de test public ne doit pas servir à un vrai portefeuille : n’importe qui pourrait en calculer le même « secret ». [3]
BIP32 utilise une reproductibilité comparable pour dériver des clés, mais ce n’est pas la même procédure que la génération générale de données aléatoires. Il construit un arbre de clés à partir d’un seed. Le chemin de dérivation sélectionne la branche utilisée. Le même seed et le même chemin permettent de retrouver les mêmes clés. Une adresse dérivée supplémentaire n’ajoute pas, à elle seule, d’entropie nouvelle et indépendante au secret initial. [4]
Dans BIP39, les mots de récupération, appelés mnemonic, ne constituent qu’une partie de l’entrée. PBKDF2 les associe à une passphrase, un secret supplémentaire facultatif, pour calculer le seed utilisé ensuite. Une autre passphrase produit un autre résultat même si les mots restent identiques. Retrouver les mêmes clés exige donc toutes les entrées initiales et la méthode de dérivation correspondante. La seule concordance des mots ne suffit pas. [5]
Une signature numérique atteste que le détenteur de la clé secrète concernée a autorisé une transaction. RFC 6979 décrit le calcul de la valeur auxiliaire k à partir de cette clé et du message signé. Cette étape n’a donc pas besoin d’une nouvelle valeur aléatoire à chaque fois. La création initiale de la clé exige toujours un bon aléa. Une procédure de signature correcte ne répare pas une clé devinable dès le départ. [6]
Retrouver les mêmes clés avec BIP32 est souhaité ; répéter par accident des valeurs censées être nouvelles ne l’est pas. Un instantané de machine virtuelle sauvegarde l’état de l’ordinateur, mémoire comprise. Comme le signale libsodium, sa restauration peut aussi répéter l’état et les sorties du générateur. Copier un environnement ne permet donc pas de supposer que chaque copie en fonctionnement produit automatiquement des secrets indépendants. [3] [4]
Le développeur compare le résultat à un vecteur de test : une entrée connue associée à la sortie attendue. Leur concordance montre que le programme calcule correctement cet exemple. Elle ne prouve pas que l’appareil réel obtient une entropie de qualité. NIST SP 800-90A distingue les mécanismes des exigences relatives à leurs entrées. Version, paramètres et apport d’entropie comptent également ; l’étiquette Deterministic RNG ne suffit pas à établir la sécurité d’un portefeuille. [1]
Pour une vision complète, lisez aussi CSPRNG, Random Number Generator, HD Wallet, Seed Generation. Cette entrée est également citée par CSPRNG, COLDCARD RNG Incident (2026).