PRNG sécurisés sur le plan cryptographique

Un CSPRNG doit satisfaire aux exigences suivantes : (1) l'imprévisibilité du bit suivant : même en connaissant tous les bits précédents, le bit suivant ne peut pas être prédit avec une probabilité supérieure à 1/2 + une quantité négligeable ; (2) la résistance à l'extension après compromission de l'état : la connaissance de l'état actuel ne révèle rien sur la sortie passée.

Sous Linux, /dev/urandom utilise un CSPRNG initialisé à partir du réservoir d’entropie. Après l’initialisation initiale (128 bits d’entropie), son utilisation reste sûre même lorsque le réservoir est « vide » : le CSPRNG conserve son propre état interne. getrandom() est l’équivalent moderne de l’appel système.

Le noyau Linux 5.17 et les versions ultérieures ont remplacé leur CSPRNG par une conception fondée sur ChaCha20. ChaCha20 est rapide (aucune accélération matérielle n’est nécessaire), fournit une sécurité de 256 bits et repose sur une preuve de sécurité bien comprise. Le nonce est le compteur ; la clé provient du réservoir d’entropie.

Fortuna (Ferguson et Schneier, 2003) est une conception de CSPRNG qui maintient 32 réservoirs d’entropie et accumule continuellement de l’entropie. Le générateur est réensemencé à partir des réservoirs à mesure qu’ils se remplissent. Il résiste aux attaques par réinitialisation du RNG et aux attaques par compromission partielle de l’état.

La norme NIST SP 800-90A incluait initialement DUAL_EC_DRBG, fondé sur les courbes elliptiques. Les documents de Snowden ont révélé que la NSA y avait inséré une porte dérobée : les points EC avaient été choisis de façon à permettre à la NSA de prédire la sortie à partir de n’importe quelle graine. N’utilisez jamais DUAL_EC_DRBG. NIST l’a supprimé en 2014.

CTR_DRBG (NIST SP 800-90A) utilise AES en mode compteur comme CSPRNG. Graine = clé de 256 bits + nonce de 128 bits. Chaque appel fait avancer le compteur. Il est largement implémenté dans OpenSSL, BoringSSL et Windows BCrypt. Il bénéficie d’une accélération matérielle sur les processeurs AES-NI.

HASH_DRBG utilise une fonction de hachage (SHA-256) de manière itérative avec une valeur de graine. HMAC_DRBG utilise HMAC pour le mélange. HMAC_DRBG est plus simple à implémenter correctement et est utilisé dans de nombreux systèmes embarqués (mbedTLS, WolfSSL).

Même les CSPRNG doivent être réensemencés périodiquement. CTR_DRBG a un intervalle de réensemencement de 2^48 requêtes. Fortuna se réensemence à partir de ses réservoirs d’entropie. Réensemencement manuel : ajoutez de l’entropie fraîche (des octets obtenus avec getrandom) à l’état du CSPRNG au démarrage et après fork().

Lorsqu’un processus crée un processus fils, le parent et l’enfant héritent du même état du CSPRNG : ils produiront une sortie identique. Pour corriger ce problème, appelez getrandom() pour réensemencer immédiatement après fork(). OpenSSL gère cela automatiquement via pthread_atfork() dans les versions récentes.

import secrets key = secrets.token_bytes(32) # clé de 256 bits nonce = secrets.token_bytes(12) # nonce de 96 bits pour AES-GCM pin = secrets.randbelow(10**6) # PIN à 6 chiffres # N’utilisez jamais le module random pour la cryptographie

window.crypto.getRandomValues(typedArray) est le CSPRNG du navigateur. Il appelle la source d’entropie de l’OS. Il est utilisé par l’API WebCrypto pour générer des clés. N’utilisez jamais Math.random() pour la sécurité : il s’agit d’un PRNG non cryptographique initialisé à partir de l’heure système.

Quel module Python devez-vous utiliser pour générer des octets aléatoires à des fins cryptographiques ?

Les CSPRNG tels que ChaCha20, CTR_DRBG et Fortuna génèrent une sortie imprévisible à partir de graines d’entropie. Évitez DUAL_EC_DRBG, random.random() et Math.random(). Utilisez secrets (Python) ou window.crypto (dans le navigateur). Ensuite : les défaillances d’entropie dans le monde réel.