Je suis curieux du générateur aléatoire cryptographiquement sécurisé standard utilisé par /dev/urandom dans Ubuntu LTS 20.04. Est-ce que quelqu'un peut nommer le standard ou me fournir une référence où je peux trouver plus d'informations, par exemple le code source?
Réponse
Trop de publicités?
C'est le "générateur de nombres aléatoires du noyau" tel que mentionné dans man 4 random, urandom :
Les fichiers spéciaux de caractères /dev/random et /dev/urandom (présents depuis Linux 1.3.30) fournissent une interface vers le générateur de nombres aléatoires du noyau. Le fichier /dev/random a un numéro de périphérique majeur 1 et un numéro de périphérique mineur 8. Le fichier /dev/urandom a un numéro de périphérique majeur 1 et un numéro de périphérique mineur 9.
Le générateur de nombres aléatoires recueille des bruits environnementaux à partir des pilotes de périphériques et d'autres sources dans un pool d'entropie. Le générateur conserve également une estimation du nombre de bits de bruit dans le pool d'entropie. À partir de ce pool d'entropie, des nombres aléatoires sont créés.
Plus d'informations sont expliquées dans les commentaires des programmeurs du fichier source associé du noyau random.c:
* Cette routine recueille des bruits environnementaux à partir des pilotes de périphériques, etc.,
* et renvoie de bons nombres aléatoires, adaptés à une utilisation cryptographique.
* Outre les utilisations cryptographiques évidentes, ces nombres sont également utiles
* pour initialiser les numéros de séquence TCP, et d'autres endroits où il est
* souhaitable d'avoir des nombres non seulement aléatoires, mais difficiles à
* prédire par un attaquant.
*
* Théorie de fonctionnement
* ========================
*
* Les ordinateurs sont des dispositifs très prévisibles. Il est donc extrêmement difficile
* de produire de vrais nombres aléatoires sur un ordinateur - par opposition à
* de pseudo-nombres aléatoires, qui peuvent facilement être générés en utilisant un
* algorithme. Malheureusement, il est très facile aux attaquants de deviner
* la séquence des générateurs de nombres pseudo-aléatoires, et pour certaines
* applications cela n'est pas acceptable. Nous devons donc essayer
* de recueillir des "bruits environnementaux" de l'environnement de l'ordinateur,
* qui doivent être difficiles pour des observateurs extérieurs à observer, et utiliser cela pour
* générer des nombres aléatoires. Dans un environnement Unix, cela est mieux fait
* à partir du noyau.
*
* Les sources d'aléatoire dans l'environnement comprennent les temps entre les touches
* de clavier, les temps entre les interruptions de certains interruptions, et autres
* événements qui sont à la fois (a) non déterministes et (b) difficiles pour un
* observateur extérieur de mesurer. Les aléas de ces sources sont
* ajoutés à un "pool d'entropie", qui est mélangé en utilisant une fonction de type CRC.
* Cela n'est pas cryptographiquement fort, mais cela est adéquat en supposant que
* l'aléatoire n'est pas choisi malicieusement, et c'est assez rapide par rapport à
* le surcoût de le faire à chaque interruption est très raisonnable.
* Alors que des octets aléatoires sont mélangés dans le pool d'entropie, les routines conservent
* une *estimation* de combien de bits de hasard ont été stockés dans
* l'état interne du générateur de nombres aléatoires.
*
* Lorsque des octets aléatoires sont souhaités, ils sont obtenus en prenant le hachage SHA
* du contenu du "pool d'entropie". Le hachage SHA évite
* d'exposer l'état interne du pool d'entropie. On croit
* qu'il est pratiquement impossible de déduire des informations utiles
* sur l'entrée de SHA à partir de sa sortie. Même s'il est possible de
* analyser SHA d'une manière astucieuse, tant que la quantité de données
* retournée par le générateur est inférieure à l'entropie inhérente dans
* le pool, les données de sortie sont totalement imprévisibles. Pour cette
* raison, la routine diminue son estimation interne de combien de
* bits de "vrai hasard" sont contenus dans le pool d'entropie au fur et à
* mesure qu'elle produit des nombres aléatoires.
*
* Si cette estimation atteint zéro, la routine peut encore générer
* des nombres aléatoires ; toutefois, un attaquant peut (au moins en théorie) être
* capable d'inférer la sortie future du générateur à partir des sorties précédentes.
* Cela nécessite une cryptanalyse réussie de SHA, ce qui est
* considéré comme peu probable, mais il y a une possibilité à distance.
* Néanmoins, ces nombres devraient être utiles pour la grande majorité
* des besoins.
