Un CSPRNG est un générateur de nombres pseudo-aléatoires cryptographiquement sûr. Il calcule de nouvelles valeurs à partir d’un état interne secret, selon une procédure précise. « Pseudo-aléatoire » ne signifie pas de mauvaise qualité : le calcul est reproductible, mais sans connaître cet état, ses résultats doivent rester imprévisibles en pratique. Il faut pour cela assez d’entropie, c’est-à-dire une incertitude sur les entrées du point de vue de l’attaquant, et une bonne intégration dans l’application.
Imaginez un programme qui crée des valeurs secrètes pour un portefeuille. Un attaquant découvre certains résultats antérieurs. Un générateur sûr ne doit pas laisser cette connaissance faciliter la prédiction des autres. C’est plus exigeant qu’une belle répartition de nombres dans un graphique. RFC 4086 distingue donc les suites cryptographiquement fortes des générateurs courants de simulation. Même un bon résultat aux tests statistiques ne suffit pas si le seed, la valeur de départ de la génération, peut être deviné. [1]
La documentation technique emploie aussi DRBG, un générateur déterministe de bits aléatoires. « Déterministe » signifie que le même état et les mêmes entrées donnent le même résultat : l’état doit donc rester secret. NIST SP 800-90A Rev. 1 décrit des mécanismes précis, Hash_DRBG, HMAC_DRBG et CTR_DRBG. Ce sont des procédés techniques, pas un label de qualité pour tout programme qui les cite. Il faut aussi examiner la configuration, l’origine de l’entropie et la manière dont le code les réalise. [2]
Une fuite de l’état pose deux questions différentes. L’attaquant peut-il retrouver les anciens résultats secrets ? Peut-il prévoir les suivants ? La protection des sorties passées s’appelle Backtracking resistance, celle des sorties futures Prediction resistance. Pour cette dernière, NIST SP 800-90A exige un apport efficace d’entropie nouvelle qui sépare les prochains résultats de l’état révélé. Relancer simplement le calcul ne rétablit pas forcément la sécurité. Disposer de l’une des protections ne démontre pas automatiquement l’autre. [2]
Une bibliothèque est un composant logiciel prêt à l’emploi, utilisable par le portefeuille. Mais son appel peut échouer. Dans OpenSSL 3.5, RAND_bytes() et RAND_priv_bytes() renvoient 1 en cas de succès, 0 pour un autre échec et -1 si la méthode actuelle n’est pas prise en charge. La génération peut être refusée si la source d’entropie échoue. Le programme doit vérifier ce résultat avant d’utiliser la zone de mémoire réservée, appelée tampon. Sinon, il risque d’employer des données qui n’ont jamais été générées de manière sûre. [3]
La reproductibilité est utile pour les tests : le développeur veut comparer un résultat à ce qu’il attend. La fonction randombytes_buf_deterministic() de libsodium produit donc la même suite avec le même seed. En fonctionnement normal, une répétition involontaire pose problème. Un instantané de machine virtuelle enregistre l’état de l’ordinateur, y compris sa mémoire ; sa restauration peut répéter l’état du générateur et ses résultats. Des copies d’un environnement ne produisent donc pas nécessairement des secrets indépendants. [4]
Un générateur peut fournir de bonnes données aléatoires que l’application traite ensuite incorrectement. Les ramener dans un intervalle autorisé plus petit par un simple reste de division peut rendre certains résultats plus fréquents que d’autres. La fonction randombytes_uniform() de libsodium évite ce biais en choisissant uniformément sous une borne supérieure donnée. Les clés doivent aussi respecter les règles de leur algorithme. Obtenir des octets aléatoires ne suffit donc pas : leur utilisation ultérieure compte tout autant. [4]
Un nonce est une valeur destinée à un usage individuel dans un procédé cryptographique. C’est toutefois le protocole qui fixe ses règles. RFC 8439 interdit de répéter un nonce avec la même clé ; une apparence aléatoire ne garantit pas l’unicité. RFC 6979 décrit au contraire le calcul déterministe de la valeur k nécessaire à une signature numérique, à partir de la clé secrète et du message signé. Il s’agit de conceptions différentes, pas d’une contradiction. « Ajouter de l’aléatoire partout » ne remplace donc pas une procédure correcte. [5] [6]
L’étiquette CSPRNG ne dit pas, à elle seule, si le portefeuille utilise correctement l’ensemble du système. Une vérification technique examine la version de la bibliothèque, le démarrage du générateur, la gestion des erreurs et le comportement après restauration ou copie de l’état. Les documents d’OpenSSL et de libsodium attestent les propriétés de leurs fonctions, pas la sécurité de toute application qui les appelle. La suite compte aussi pour l’utilisateur : même un secret parfaitement généré ne protège plus les fonds si une sauvegarde permettant de rétablir l’accès est ensuite divulguée. [3] [4]
Pour une vision complète, lisez aussi Cryptographic Entropy, Random Number Generator, Deterministic RNG, Seed Generation. Cette entrée est également citée par Dice Roll Entropy, Cryptographic Entropy, Random Number Generator, Deterministic RNG.