Solution 1 :
Votre système rassemble des "vrais" nombres aléatoires en gardant un œil sur différents événements :l'activité du réseau, le générateur de nombres aléatoires matériel (si disponible ; par exemple, les processeurs VIA ont généralement un "vrai" générateur de nombres aléatoires), etc. Si alimente ceux-ci vers le pool d'entropie du noyau, qui est utilisé par /dev/random. Les applications qui ont besoin d'une sécurité extrême ont tendance à utiliser /dev/random comme source d'entropie, ou en d'autres termes, la source aléatoire.
Si /dev/random manque d'entropie disponible, il est incapable de fournir plus d'aléatoire et l'application en attente d'aléatoire se bloque jusqu'à ce que plus de choses aléatoires soient disponibles. L'exemple que j'ai vu au cours de ma carrière est que le démon Cyrus IMAP voulait utiliser /dev/random pour le caractère aléatoire et ses sessions POP voulaient générer les chaînes aléatoires dans les connexions APOP à partir de /dev/random. Dans un environnement occupé, il y avait plus de tentatives de connexion que de trafic pour alimenter le /dev/random -> tout était bloqué. Dans ce cas, j'ai installé rng-tools et activé le rngd qu'il avait - qui a pelleté des nombres semi-aléatoires de /dev/urandom à /dev/random au cas où /dev/random manquait d'entropie "réelle".
Solution 2 :
Si vous souhaitez un aperçu plus simple du problème sous-jacent :certaines applications (telles que le chiffrement) ont besoin de nombres aléatoires. Vous pouvez générer des nombres aléatoires à l'aide d'un algorithme - mais bien que ceux-ci semblent aléatoires dans un sens, ils sont totalement prévisibles dans un autre. Par exemple, si je vous donne les chiffres 58209749445923078164062862089986280348253421170679, ils semblent assez aléatoires. Mais si vous réalisez qu'il s'agit en fait de chiffres de PI, vous saurez que le prochain sera 8.
Pour certaines applications, c'est OK, mais pour d'autres applications (en particulier celles liées à la sécurité), les gens veulent un véritable hasard imprévisible - qui ne peut pas être généré par un algorithme (c'est-à-dire un programme) car c'est par définition prévisible. Il s'agit d'un problème dans la mesure où votre ordinateur est essentiellement un programme, alors comment peut-il obtenir de véritables nombres aléatoires ? La réponse est en mesurant des événements véritablement aléatoires du monde extérieur - par exemple les écarts entre vos pressions sur les touches et en les utilisant pour injecter un véritable caractère aléatoire dans le générateur de nombres aléatoires autrement prévisible. Le "pool d'entropie" pourrait être considéré comme le magasin de ce caractère aléatoire qui est accumulé par les frappes (ou tout ce qui est utilisé) et drainé par la génération de nombres aléatoires.
Solution 3 :
L'entropie est un terme technique pour "aléatoire". Les ordinateurs ne génèrent pas vraiment d'entropie, mais la collectent en examinant des éléments tels que les variations de la vitesse de rotation des disques durs (un phénomène physique très difficile à prévoir en raison de la friction, etc.). Lorsqu'un ordinateur veut générer des données pseudo-aléatoires, il sèmera un formule mathématique avec une véritable entropie trouvée en mesurant les clics de souris, les variations de rotation du disque dur, etc. En gros entropy_avail est la mesure des bits actuellement disponibles pour être lus à partir de /dev/random
Il faut du temps à l'ordinateur pour lire l'entropie de son environnement à moins qu'il n'ait un matériel cool comme une diode bruyante ou quelque chose comme ça.
Si vous avez 4096 bits d'entropie disponibles et que vous cat /dev/random vous pouvez vous attendre à pouvoir lire 512 octets d'entropie (4096 bits) avant que le fichier ne se bloque en attendant plus d'entropie.
Par exemple si vous "cat /dev/random ” votre entropie se réduira à zéro. Au début, vous obtiendrez 512 octets de déchets aléatoires, mais cela s'arrêtera et petit à petit, vous verrez plus de données aléatoires s'écouler.
Ce n'est pas comme ça que les gens devraient fonctionner /dev/random pourtant. Normalement, les développeurs liront une petite quantité de données, comme 128 bits, et l'utiliseront pour semer une sorte d'algorithme PRNG. Il est poli de ne plus lire l'entropie de /dev/random que vous n'en avez besoin car cela prend tellement de temps à se construire et est considéré comme précieux. Ainsi si vous le videz par négligence cat en utilisant le fichier comme ci-dessus, vous provoquerez d'autres applications qui doivent lire à partir de /dev/random bloquer. Sur un système au travail, nous avons remarqué que de nombreuses fonctions de chiffrement étaient bloquées. Nous avons découvert qu'une tâche cron appelait un script python qui n'arrêtait pas d'initialiser ramdom.random() sur chaque course qui a couru toutes les quelques secondes. Pour résoudre ce problème, nous avons réécrit le script python afin qu'il s'exécute en tant que démon initialisé une seule fois et que la tâche cron lise les données via XMLRPC afin qu'elle ne continue pas à lire depuis /dev/random au démarrage.
Solution 4 :
Le fichier en lecture seule entropy_avail donne l'entropie disponible. Normalement, ce sera 4096 (bits), un pool d'entropie complet.
Vous pouvez en savoir plus sur :http://linux.die.net/man/4/random