Nombres pseudo-aléatoires et véritablement aléatoires : quelle est la différence, et comment les distinguer ?

Le sujet des nombres aléatoires dérape vite, car des choses très différentes sont toutes désignées par le seul mot « aléatoire ». Une suite calculée par quelque chose comme Math.random() et une suite obtenue à partir d’un phénomène physique comme le bruit thermique ou la gigue d’horloge paraissent toutes deux raisonnablement dispersées, si l’on ne juge que sur l’apparence.

En pratique, pourtant, laisser cette distinction dans le flou expose à des erreurs de jugement de ce genre :

• On veut des exécutions de simulation reproductibles, mais les résultats varient à chaque fois
• On génère des jetons de réinitialisation de mot de passe avec des nombres aléatoires faciles à prédire
• On réussit une batterie de tests statistiques et on en conclut « c’est du véritable aléatoire »
• À l’inverse, on entend le mot « pseudo » et on suppose que c’est forcément dangereux

Cet article présente, sous une forme directement exploitable en pratique, ce qu’est un nombre pseudo-aléatoire, ce qu’est un nombre véritablement aléatoire, et comment les distinguer. L’accent est mis sur le jugement porté à la construction du générateur, et non sur l’apparence de la sortie.

Le contenu s’appuie sur la documentation officielle du NIST, de l’IETF, des systèmes d’exploitation et des langages, vérifiable en avril 2026.

Table des matières

1. La conclusion d’abord (en une phrase)
2. Ce que cet article entend par « pseudo-aléatoire » et « véritablement aléatoire »
3. Vue d’ensemble en une page
   • 3.1. Schéma des relations
   • 3.2. Le glossaire le plus court possible
4. Qu’est-ce qu’un nombre pseudo-aléatoire ?
   • 4.1. En une phrase
   • 4.2. Distinguer le PRNG ordinaire et le CSPRNG
5. Qu’est-ce qu’un nombre véritablement aléatoire ?
   • 5.1. En une phrase
   • 5.2. Même l’aléatoire physique n’est pas forcément utilisé brut
6. Ce qui diffère réellement
   • 6.1. Origine de la génération
   • 6.2. Reproductibilité
   • 6.3. Prévisibilité
   • 6.4. Vitesse et exploitation
7. Comment les distinguer
   • 7.1. La sortie seule ne permet pas, en principe, de trancher
   • 7.2. Ce qu’il faut regarder en premier : la conception du générateur
   • 7.3. Ensuite, chercher des défauts évidents avec des tests statistiques
   • 7.4. Pour un usage de sécurité, se placer du point de vue de l’attaquant
8. Quoi utiliser selon l’usage
9. Idées reçues courantes
10. Un tableau de décision pour les cas d’hésitation
11. Résumé
12. Références

1. La conclusion d’abord (en une phrase)

Formulé de façon un peu abrupte, mais utile au quotidien :

• Les nombres pseudo-aléatoires sont des suites produites de façon déterministe à partir d’un état interne et d’un algorithme
• Les nombres véritablement aléatoires sont des suites dont la source d’entropie est un phénomène physique comme le bruit thermique ou la gigue
• Cependant, la plupart des API de génération de nombres aléatoires sûres utilisées en pratique ne renvoient pas de l’aléatoire physique brut : elles renvoient un DRBG / CSPRNG initialisé à partir d’une source d’entropie
• On ne peut donc pas les distinguer en se demandant simplement « est-ce que ça a l’air aléatoire ». Ce qu’il faut regarder, c’est la construction du générateur, la façon dont la graine est injectée, le réamorçage (reseed) et les health tests
• Pour les simulations et les tests reproductibles, la reproductibilité des nombres pseudo-aléatoires est un atout
• Pour les usages de sécurité comme les clés, les jetons ou les nonces, la règle de base est d’utiliser l’API de génération de nombres aléatoires sûre fournie par l’OS ou le langage

En résumé, on se trompe rarement en distinguant d’abord ces trois cas :

1. Est-ce qu’il s’agit d’un PRNG ordinaire ?
2. Est-ce qu’il s’agit d’un PRNG cryptographique / CSPRNG / DRBG ?
3. Est-ce qu’il s’agit d’un NRBG / TRNG doté d'une source d'entropie physique ?

2. Ce que cet article entend par « pseudo-aléatoire » et « véritablement aléatoire »

Dans cette discussion, dire simplement « nombre aléatoire » couvre un champ trop large. Fixons d’abord les définitions.

• Nombre pseudo-aléatoire (PRNG) : suite générée par une procédure déterministe à partir d’une graine et d’un état interne. Dans les mêmes conditions, on obtient la même suite
• Nombre pseudo-aléatoire cryptographique (CSPRNG / DRBG) : un type de nombre pseudo-aléatoire, mais qui privilégie l’imprévisibilité. La norme NIST SP 800-90A définit ce deterministic random bit generator
• Nombre véritablement aléatoire : dans le langage courant, cela désigne le plus souvent un aléatoire « authentique » ou « physique ». Dans la terminologie du NIST, le terme le plus proche est NRBG (non-deterministic random bit generator), décrit comme un générateur qui accède en permanence à une source d’entropie et qui, lorsqu’il fonctionne normalement, produit une sortie de pleine entropie (full entropy)

Le point important ici est que « pseudo-aléatoire » et « aléatoire dangereux » ne sont pas synonymes.

Par exemple, des PRNG rapides comme les générateurs congruentiels linéaires ou le simple xorshift, et des CSPRNG comme CTR_DRBG ou HMAC_DRBG, sont tous deux déterministes, mais leurs implications en matière de sécurité sont très différentes.

3. Vue d’ensemble en une page

3.1. Schéma des relations

Le plus rapide est de visualiser d’abord la position de chaque concept sur un seul schéma.

flowchart LR
    NOISE["Phénomène physique<br/>bruit thermique, gigue, etc."] --> ENT["Source d'entropie"]
    ENT --> SEED["seed / reseed"]
    SEED --> DRBG["DRBG / CSPRNG<br/>déploie l'aléatoire à grande vitesse"]
    DRBG --> API["Nombres aléatoires renvoyés par l'OS / la bibliothèque"]

    STATE["État interne + formule"] --> PRNG["PRNG ordinaire"]
    PRNG --> OUT["Suite qui paraît aléatoire"]

Ce qu’il faut retenir ici, c’est que la sortie de l’« API de génération de nombres aléatoires sûre » reçue par l’application diffère un peu à la fois du PRNG ordinaire à droite et du bruit physique brut à gauche.

La plupart des implémentations s’initialisent / se réamorcent (seed / reseed) à partir de la source d’entropie de gauche, puis renvoient des valeurs déployées à grande vitesse par un DRBG / CSPRNG. Les normes NIST SP 800-90B et 800-90C organisent précisément cette construction « source d’entropie + générateur déterministe ».

3.2. Le glossaire le plus court possible

Le moyen mnémotechnique le plus court :

• Le PRNG ordinaire, c’est « de l’aléatoire qu’on peut reproduire »
• Le CSPRNG, c’est « de l’aléatoire qu’on peut reproduire, mais construit pour être difficile à prédire de l’extérieur »
• Le véritable aléatoire, c’est « de l’aléatoire qui extrait de l’entropie d’un phénomène physique »

4. Qu’est-ce qu’un nombre pseudo-aléatoire ?

4.1. En une phrase

Un générateur de nombres pseudo-aléatoires calcule une « suite qui a l’air aléatoire » tout en mettant à jour un état interne.

Donnez-lui la même graine, exécutez le même algorithme, tirez le même nombre de valeurs : vous obtenez la même suite. Cela ressemble à un défaut, mais pour la simulation, les tests et le débogage, c’est en réalité un atout majeur.

C’est justement parce que c’est reproductible qu’on peut travailler en disant « c’est cette graine qui déclenche le bug » ou « je veux comparer à nouveau avec le résultat d’hier ».

4.2. Distinguer le PRNG ordinaire et le CSPRNG

C’est le point le plus souvent mal compris. « Pseudo-aléatoire = faux = à ne jamais utiliser » est une erreur.

La norme NIST SP 800-90A définit des générateurs de bits aléatoires déterministes construits sur des fonctions de hachage et des chiffrements par bloc. Autrement dit, une grande partie du cœur de l’aléatoire utilisé à des fins cryptographiques est elle-même un générateur déterministe.

La différence ne tient pas à un simple « air d’aléatoire », mais à l’imprévisibilité du point de vue de l’attaquant.

• PRNG ordinaire
  • Rapide
  • Facile à reproduire
  • Facile à prédire dès que l’état interne ou la graine fuite
• CSPRNG / DRBG
  • Également déterministe
  • Mais conçu de façon à rendre la sortie difficile à prédire, en supposant que l’état interne reste inconnu
  • C’est celui à utiliser pour les usages de sécurité

Juger de la sécurité en se demandant seulement « est-ce pseudo-aléatoire ? » conduit donc presque toujours à se tromper. Ce qu’il faut regarder, c’est « quel générateur pseudo-aléatoire ? ».

5. Qu’est-ce qu’un nombre véritablement aléatoire ?

5.1. En une phrase

Les nombres véritablement aléatoires extraient de l’entropie d’une indétermination physique : bruit thermique, gigue d’oscillateur, bruit d’avalanche, phénomènes quantiques, et autres sources du même ordre.

Dans le langage courant, on parle d’aléatoire « authentique » ou « physique ». Dans la terminologie du NIST, le concept le plus proche est le NRBG : un générateur qui accède en permanence à une source d’entropie et qui, tant qu’il fonctionne correctement, produit une sortie de pleine entropie.

5.2. Même l’aléatoire physique n’est pas forcément utilisé brut

Ce point compte aussi. Être « véritablement aléatoire » ne signifie pas que les mesures brutes sont transmises telles quelles à l’application.

Les sources physiques présentent plusieurs difficultés pratiques :

• Elles présentent un biais
• Elles subissent l’influence de la température, de l’alimentation, des pannes et du vieillissement
• Le débit de sortie brut peut être assez faible
• Sans contrôle de santé (health check), une source défaillante passe facilement inaperçue

C’est pourquoi la norme NIST SP 800-90B met l’accent sur les principes de conception des sources d’entropie, la notion de min-entropy, les tests de validation et les health tests. Et, en tant qu’implémentation d’ensemble, on retrouve le plus souvent la construction « source d’entropie + DRBG » décrite dans la norme NIST SP 800-90C.

En définitive, le « véritable aléatoire » n’est pas une substance brute mystérieuse : c’est quelque chose qu’on gère avec la source physique, son évaluation, sa surveillance et son post-traitement.

6. Ce qui diffère réellement

Les différences entre types de nombres aléatoires ne peuvent pas être résumées par le seul critère « est-ce que ça a l’air aléatoire ». Au minimum, ces quatre axes permettent d’y voir clair.

6.1. Origine de la génération

• Pseudo-aléatoire : un algorithme et un état interne
• Véritablement aléatoire : une source d’entropie physique

C’est la différence la plus fondamentale.

6.2. Reproductibilité

• Pseudo-aléatoire : reproductible avec la même graine
• Véritablement aléatoire : régénérer dans les mêmes conditions donne rarement la même suite

La reproductibilité est un atout pour les tests, et peut devenir une faiblesse pour un tirage au sort.

6.3. Prévisibilité

• PRNG ordinaire : dès que la graine ou l’état interne devient lisible, une bonne partie de l’avenir est connue
• CSPRNG : conçu pour résister à l’anticipation, tant que l’état interne reste protégé
• Véritablement aléatoire : difficile à prédire si la source physique est saine, mais un défaut de capteur ou une conception mal pensée est un problème distinct

En sécurité, c’est cet axe qui compte le plus. Ce qui importe, ce n’est pas à quel point la sortie paraît dispersée, mais si l’on peut deviner la valeur suivante.

6.4. Vitesse et exploitation

• Pseudo-aléatoire : rapide, stable, facile à mettre en œuvre
• Véritablement aléatoire : nécessite une collecte d’entropie et une surveillance, avec des contraintes sur la vitesse et le coût d’implémentation

C’est pourquoi, dans les systèmes en production, le choix réaliste n’est ni « uniquement du véritable aléatoire » ni « uniquement du pseudo-aléatoire », mais un CSPRNG initialisé avec de l'entropie physique.

7. Comment les distinguer

7.1. La sortie seule ne permet pas, en principe, de trancher

Voici la réponse la plus importante : on ne peut pas regarder une suite de sortie finie et affirmer « c’est du véritable aléatoire ».

La raison est simple : on peut toujours construire un programme déterministe qui renvoie exactement la même suite finie que celle qu’on vient d’observer. À la limite, il suffit d’intégrer cette suite dans un tableau ou une ROM et de la restituer dans l’ordre.

Donc « ça paraît naturel, donc c’est authentique » ne tient pas. La norme NIST SP 800-22 précise elle aussi que les tests statistiques ne sont qu’une première étape et ne prouvent en aucun cas, à eux seuls, la validité d’un générateur.

À l’inverse, un bon CSPRNG est justement construit pour être très difficile à distinguer du véritable aléatoire par sa seule sortie. Ici, l’« indistinguabilité » est l’objectif de conception, et non un problème.

7.2. Ce qu’il faut regarder en premier : la conception du générateur

Pour distinguer les deux, il est plus pertinent de vérifier les points suivants que de se fier à l’apparence de la sortie.

• Quel est l’algorithme de génération
  • Un simple PRNG, ou un DRBG / CSPRNG ?
• D’où vient la graine
  • Une graine fixe, l’horloge, le PID ?
  • Ou la source d’entropie de l’OS ?
• Y a-t-il un réamorçage (reseed)
  • Une initialisation unique au démarrage, sans jamais y revenir ?
  • Ou une réinjection en cours de fonctionnement ?
• La source d’entropie est-elle validée
  • Évaluation du min-entropy
  • Health tests
  • Détection de panne
• Quelle API est utilisée
  • Une implémentation maison ?
  • L’API standard de l’OS / du langage ?

En regardant sous cet angle, on peut trancher dans un grand nombre de cas.

• « Fixer la graine donne toujours la même suite » → pseudo-aléatoire
• « Il existe une source d’entropie physique, avec validation / health tests prévus » → une conception dotée d’une source de véritable aléatoire
• « L’API secure RNG de l’OS est appelée » → il s’agit le plus souvent d’un hybride entropie physique + CSPRNG

7.3. Ensuite, chercher des défauts évidents avec des tests statistiques

Les tests statistiques ne sont pas inutiles, bien au contraire : ils sont importants. Mais leur rôle se rapproche davantage de la « détection de défauts » que de la « preuve ».

On y examine typiquement les points suivants :

• Biais entre les 0 et les 1
• Biais dans les runs (séquences de valeurs identiques consécutives)
• Périodicité
• Corrélation
• Entropie approximative
• Complexité linéaire

La norme NIST SP 800-22 — et, au Japon, l’ensemble minimal de tests d’aléatoire du CRYPTREC — sont fréquemment cités en référence. Ils sont efficaces pour vérifier « cette suite présente-t-elle un biais ou une structure anormale ».

Mais réussir ces tests ne fait pas d’un générateur du « véritable aléatoire ». Un CSPRNG bien conçu les réussit couramment, et à l’inverse, même une véritable source d’aléatoire physique peut échouer à cause d’un biais de capteur ou d’une panne.

La place des tests, en résumé :

• Réussite : aucun défaut flagrant n’est visible, pour l’instant
• Échec : il y a probablement un problème quelque part
• Preuve d’authenticité : cela, ils ne peuvent pas l’affirmer

7.4. Pour un usage de sécurité, se placer du point de vue de l’attaquant

Pour les jetons de réinitialisation de mot de passe, les identifiants de session, les nonces ou la génération de clés, la question « est-ce du véritable aléatoire ? » ne suffit pas.

Ce qu’il faut vraiment examiner, c’est si un attaquant peut prédire la valeur suivante.

Par exemple :

• Initialiser uniquement avec l’heure courante
• Se contenter de mélanger un identifiant de processus ou un numéro séquentiel
• Une implémentation maison sans évaluation de la qualité de la graine
• Détourner des API de la famille random à des fins de sécurité

Rien de tout cela n’est empêché par le simple fait que « la sortie paraît plausible ».

L’IPA (l’agence japonaise pour la promotion des technologies de l’information) recommande également de connaître les API et bibliothèques existantes liées à la sécurité, et d’éviter les implémentations maison faites à la légère. Python indique explicitement de privilégier le module secrets plutôt que random. En Java, c’est SecureRandom qui occupe cette place.

En définitive, en sécurité, la question « utilise-t-on une graine / entropie sûre et une API sûre ? » compte plus que « pseudo ou véritable ? ».

8. Quoi utiliser selon l’usage

Au niveau de l’implémentation, les choix sûrs sont les suivants :

• Windows natif : BCryptGenRandom
• .NET : System.Security.Cryptography.RandomNumberGenerator
• Linux : getrandom()
• Python : secrets
• Java : SecureRandom

Pour Windows, Microsoft Learn documente que le fournisseur par défaut derrière BCryptGenRandom est conforme au CTR_DRBG de la norme NIST SP800-90. Le getrandom() de Linux est de la même façon documenté comme fournissant des octets aléatoires utilisables à des cryptographic purposes. Le RandomNumberGenerator de .NET, le secrets de Python et le SecureRandom de Java sont chacun des API conçues avec les usages cryptographiques à l’esprit.

9. Idées reçues courantes

9.1. « Réussir les tests statistiques prouve le véritable aléatoire »

Faux. Cela ne prouve rien de plus qu’« aucun biais flagrant n’est visible ».

9.2. « Le véritable aléatoire est toujours sûr »

Faux. Une panne de la source physique, un biais, un défaut d’implémentation ou l’absence de health tests dégradent tous la qualité.

9.3. « Les nombres pseudo-aléatoires sont tous dangereux »

Faux. Les CSPRNG / DRBG constituent, au contraire, le cœur des API de génération de nombres aléatoires sûres utilisées en pratique.

9.4. « Pour la sécurité, il faut utiliser uniquement de l’aléatoire physique brut, directement »

Pas nécessairement. En pratique, la combinaison d’une source d’entropie physique et d’un CSPRNG est la norme.

9.5. « random ou Math.random() disperse déjà assez bien, donc on peut s’en servir pour un jeton »

Mauvais usage. La dispersion visuelle et l’imprévisibilité face à un attaquant sont deux choses différentes.

10. Un tableau de décision pour les cas d’hésitation

En cas d’hésitation, voici l’ordre de réflexion à suivre :

1. Voulez-vous pouvoir reproduire les mêmes résultats ?
   • Oui → PRNG ordinaire
   • Non → étape suivante
2. Est-ce problématique qu’un attaquant puisse prédire la valeur ?
   • Oui → l’API secure RNG standard de l’OS / du langage
   • Non → choisissez selon les exigences de qualité et la vitesse
3. Faut-il rendre compte de la source d’aléatoire elle-même ou l’auditer ?
   • Oui → envisagez une source d’aléatoire physique ou un service certifié
4. Voulez-vous l’implémenter vous-même ?
   • L’envie est compréhensible, mais l’aléatoire est un domaine où l’on se trompe facilement ; commencez par utiliser l’API standard

En suivant cet ordre, on arrête une politique bien plus vite qu’en s’attardant sur l’opposition binaire « pseudo ou véritable ? ».

11. Résumé

Pour résumer la différence entre nombres pseudo-aléatoires et nombres véritablement aléatoires de la façon la plus brute mais la plus utile en pratique :

• Les nombres pseudo-aléatoires sont fabriqués par le calcul
• Les nombres véritablement aléatoires puisent leur entropie dans des phénomènes physiques
• Mais les API de génération de nombres aléatoires sûres utilisées en pratique se situent surtout dans l’entre-deux : source d'entropie + CSPRNG

Autrement dit, ce qu’il faut regarder, ce n’est pas l’apparence, mais la construction.

• On ne peut pas conclure, à partir de la seule sortie, si quelque chose est authentique
• Les tests statistiques aident à détecter des défauts, mais ne constituent pas une preuve
• En sécurité, « peut-on le prédire ? » est le cœur du sujet
• Si vous avez besoin de reproductibilité, utilisez un PRNG ; si vous avez besoin d’imprévisibilité, utilisez l’API secure RNG standard de l’OS / du langage

En raisonnant ainsi, on échappe à l’opposition simpliste « le pseudo-aléatoire, c’est du faux ? ».

12. Références

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators Le document fondateur sur les générateurs de bits aléatoires déterministes.

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation Organise la réflexion sur les sources d’entropie, la validation et les health tests.

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions Organise la construction « source d’entropie + DRBG ».

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications Explique la place des tests statistiques. Le point clé : un test est une première étape, pas une preuve.

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG) Utile pour vérifier le terme NIST le plus proche du « véritable aléatoire ».

6. RFC 4086: Randomness Requirements for Security Organise les précautions relatives à l’aléatoire et aux sources d’entropie pour les usages de sécurité.

7. Microsoft Learn: BCryptGenRandom function Décrit l’API secure RNG de Windows et le CTR_DRBG du fournisseur par défaut.

8. Linux man page: getrandom(2) L’API d’aléatoire de Linux, utilisable à des cryptographic purposes.

9. Microsoft Learn: RandomNumberGenerator Class L’API RNG cryptographiquement robuste de .NET.

10. Python documentation: secrets — Generate secure random numbers for managing secrets Les bases de la gestion d’un aléatoire de qualité sécurité en Python.

11. Oracle Java Documentation: SecureRandom Résume le RNG sûr de Java et son approche des graines / de l’entropie.

12. IPA: 第3章 3.破られにくい暗号技術と擬似乱数の使用 Couvre, en japonais, l’importance de la graine, les tests et les précautions d’usage des API.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre un nombre pseudo-aléatoire et un nombre véritablement aléatoire (aléatoire véritable) ?

Un nombre pseudo-aléatoire (PRNG) est une suite construite de façon déterministe par un algorithme, à partir d'une graine (seed) et d'un état interne : dans les mêmes conditions, on obtient exactement la même suite. Un nombre véritablement aléatoire est une suite dont la source d'entropie est un phénomène physique, comme le bruit thermique ou la gigue (jitter) d'un oscillateur ; en général, on n'obtient pas la même suite si on la régénère dans les mêmes conditions. Cela dit, la plupart des API de génération de nombres aléatoires sûres utilisées en pratique ne renvoient pas directement de l'aléatoire physique brut : elles renvoient un CSPRNG / DRBG initialisé (seedé) à partir d'une source d'entropie physique, ce qui constitue une construction hybride.

Peut-on distinguer un nombre pseudo-aléatoire d'un nombre véritablement aléatoire simplement en regardant la sortie ?

On ne peut pas affirmer, en observant seulement une suite finie de sorties, qu'il s'agit de véritable aléatoire. La raison est qu'on peut toujours construire un programme déterministe qui renvoie exactement la même suite que celle observée. Pour distinguer les deux, il est plus pertinent de ne pas se fier à l'apparence de la sortie, mais d'examiner la construction du générateur lui-même : quel est l'algorithme de génération, d'où vient la graine, y a-t-il un réamorçage (reseed), la source d'entropie est-elle validée (évaluation du min-entropy, health test), et quelle API est utilisée.

Réussir des tests statistiques prouve-t-il qu'un générateur est véritablement aléatoire ?

Non. Le rôle des tests statistiques se rapproche davantage de la détection de défauts que de la preuve. La norme NIST SP 800-22 précise elle-même que les tests statistiques ne sont qu'une première étape et ne prouvent en aucun cas, à eux seuls, la validité d'un générateur. Un CSPRNG bien conçu passe ces tests sans difficulté, et inversement, une source d'aléatoire physique authentique peut échouer à cause d'un biais de capteur ou d'une panne. Réussir les tests signifie qu'aucun défaut flagrant n'est visible pour l'instant ; échouer signale qu'il y a probablement un problème quelque part.

Quelle API de génération de nombres aléatoires utiliser pour des usages de sécurité ?

Pour des usages comme les clés, les jetons (tokens), les nonces ou les identifiants de session, la règle de base est d'utiliser l'API de génération de nombres aléatoires sûre fournie par l'OS ou le langage, plutôt qu'une implémentation maison. Concrètement : BCryptGenRandom sur Windows natif, System.Security.Cryptography.RandomNumberGenerator en .NET, getrandom() sous Linux, le module secrets en Python, et SecureRandom en Java. Il faut éviter une implémentation maison initialisée avec l'heure courante ou l'identifiant de processus, ainsi que le détournement d'API de la famille random à des fins de sécurité.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.