Les données / dev / random sont-elles un chiffre AES pseudo-aléatoire, et d'où vient l'entropie?

Ma compréhension actuelle d'un pool d'entropie est qu'il rassemble des bits de données vraiment aléatoires à un rythme lent. J'aimerais savoir comment Unix et Linux collectent l'entropie et comment cette entropie est utilisée par / dev / random.

J'ai entendu (de manière générique) des méthodes de collecte d'entropie telles que l'état du processeur de la carte vidéo lorsqu'un paquet réseau sélectionné "au hasard" arrive, comparé au facteur de sifflement dans le convertisseur numérique-analogique et à d'autres méthodes encore plus obtuses.

Je crois que le "pool" d'entropie est exploité au besoin, et est utilisé pour amorcer un générateur aléatoire psuedo ....

Je ne suis pas après une réponse approfondie, mais je suis intéressé de savoir s'il s'agit de l'approche générale utilisée par Unix / Linux? .. et peut-être quelques indices sur ce qui se passe réellement au charbon-collection d'entropie. .. et ensuite, à quoi sert l'entropie .. Est-ce un chiffre AES Rijndael?

Les informations de base pour mes condamnations ci-dessus proviennent de Security Now de Steve Gibson ! podcast: Episode # 301 Going Random, Partie 2 de 2 ... Il ne parlait que de manière générique (mais comme son style, avec suffisamment de détails et de clarté pour que même moi je puisse le comprendre. Ayant écouté les 300 épisodes précédents aide :), ... et j'aimerais savoir si c'est comme ça qu'Unix / Linux le fait ...

Linux a deux générateurs de nombres aléatoires disponibles pour l'espace utilisateur, /dev/randomet /dev/urandom.

/dev/randomest une source de "vrai" caractère aléatoire - c'est-à-dire qu'il n'est pas généré par un générateur de nombres pseudo-aléatoires. L'entropie est alimentée par le pilote d'entrée et le gestionnaire d'interruption, via les fonctions add_input_randomnesset add_interrupt_randomness. Les processus de lecture de cet appareil se bloqueront si l'entropie s'épuise.

/dev/urandomest un générateur de nombres pseudo-aléatoires. Il est alimenté par le même pool d'entropie que /dev/random, mais lorsque celui-ci s'épuise, il passe à un générateur cryptographiquement puissant.

Les applications de l'espace utilisateur peuvent alimenter le pool d'entropie en écrivant dans /dev/{,u}random.

Lisez la page de manuel random (4) et le fichier drivers/char/random.cdans l'arborescence des sources du noyau. Il est bien commenté et la plupart de ce que vous demandez y est expliqué.

/dev/randomPar défaut, FreeBSD est un générateur de nombres pseudo-aléatoires utilisant l'algorithme Yarrow (mais peut pointer vers un RNG matériel s'il est connecté). Le générateur de logiciel prend l'entropie des connexions Ethernet et série et des interruptions matérielles (modifiables via sysctl kern.random). L'algorithme Yarrow est censé être sécurisé tant que l'état interne est inconnu, il /dev/randomdoit donc toujours produire des données de haute qualité sans blocage. Voir aléatoire (4) .

Sur NetBSD, /dev/randomfournit des données aléatoires basées uniquement sur l'entropie collectée (à partir des disques, du réseau, des périphériques d'entrée et / ou des lecteurs de bande; réglable à l'aide de rndctl ), tout en retombant/dev/urandom sur un PRNG lorsque le pool d'entropie est vide, semblable à Linux. Voir random (4) , rndctl (8) , rnd (9) .

OpenBSD a quatre générateurs: /dev/randomest un générateur matériel, /dev/srandomest un générateur de données aléatoires sécurisé (utilisant MD5 sur le pool d'entropie: "interruptions de disque et de périphérique réseau et autres"), /dev/urandomest similaire mais retombe sur un PRNG lorsque le pool d'entropie est vide. Le quatrième, /dev/arandomest également un PRNG mais utilise RC4 . Voir random (4) , arc4random (3) .

Mac OS X utilise également l'algorithme Yarrow pour /dev/random, mais a un fonctionnement identique /dev/urandompour la compatibilité. "Une entropie supplémentaire est fournie régulièrement au générateur par le démon SecurityServer à partir de mesures de gigue aléatoires du noyau." Voir aléatoire (4) .