Expliquez en anglais simple sur l'entropie disponible

Si j'exécute cette commande dans Ubuntu

sudo cat /proc/sys/kernel/random/entropy_avail

il renvoie un nombre qui indique combien "d'entropie" est disponible pour le noyau, mais c'est à peu près tout ce que je sais. Dans quelle unité cette entropie est-elle mesurée? A quoi cela sert? On m'a dit que c'était "mauvais" si ce nombre était "bas". Quel est le niveau «faible» et quelles «mauvaises» choses se passeront-elles si elles le sont? Quelle est la bonne plage pour cela? Comment est-il déterminé?

Votre système collecte des nombres aléatoires «réels» en surveillant les différents événements: activité du réseau, générateur de nombres aléatoires matériel (si disponible; par exemple, les processeurs VIA ont généralement un générateur de nombres aléatoires «réels»), etc. Si les alimente au pool d'entropie du noyau, qui est utilisé par / dev / random. Les applications qui nécessitent une sécurité extrême ont tendance à utiliser / dev / random comme source d'entropie, ou en d'autres termes, la source d'aléatoire.

Si / dev / random ne dispose plus de l'entropie disponible, il est impossible de fournir plus d'aléatoire et l'application attend que l'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 l'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 manquerait d'entropie "réelle".

Si vous souhaitez un aperçu plus simple du problème sous-jacent: certaines applications (telles que le chiffrement) nécessitent des nombres aléatoires. Vous pouvez générer des nombres aléatoires à l'aide d'un algorithme - mais bien qu'ils semblent aléatoires dans un sens, ils sont totalement prévisibles dans un autre. Par exemple, si je vous donne les chiffres 58209749445923078164062862089986280348253421170679, ils ont l'air assez aléatoires. Mais si vous réalisez qu'il s'agit en fait de chiffres de PI, alors 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 caractère aléatoire 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. C'est un problème dans la mesure où votre ordinateur est essentiellement un programme, alors comment peut-il éventuellement obtenir de vrais 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 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 stockage de ce caractère aléatoire qui est constitué par les frappes (ou tout ce qui est utilisé) et drainé par la génération de nombres aléatoires.

L'entropie est un terme technique pour «aléatoire». Les ordinateurs ne génèrent pas vraiment d'entropie mais les collectent en regardant des choses comme les variations de vitesse de rotation du disque dur (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 le fera créer une 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_availla mesure des bits actuellement disponibles pour être lus/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.

Si vous disposez de 4096 bits d'entropie et que vous /dev/randompensez que vous pouvez être en mesure de lire 512 octets d'entropie (4096 bits) avant que le fichier ne bloque pendant qu'il attend plus d'entropie.

Par exemple, si vous " cat /dev/random" votre entropie se réduira à zéro. Au début, vous obtiendrez 512 octets d'ordures aléatoires, mais cela s'arrêtera et, petit à petit, vous verrez plus de creux de données aléatoires.

Ce n'est pas ainsi que les gens devraient fonctionner /dev/random. Normalement, les développeurs liront une petite quantité de données, comme 128 bits, et l'utiliseront pour créer une sorte d'algorithme PRNG. Il est poli de ne pas lire plus d'entropie /dev/randomque nécessaire, car cela prend beaucoup de temps à construire et est considéré comme précieux. Ainsi, si vous le vidangez en catnégligeant le fichier comme ci-dessus, vous bloquerez d'autres applications qui ont besoin de lire /dev/random. Sur un système au travail, nous avons remarqué que de nombreuses fonctions de cryptage se bloquaient. Nous avons découvert qu'un travail cron appelait un script python qui continuait à s'initialiserramdom.random()sur chaque course qui a fonctionné 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 qui ne s'est initialisé qu'une seule fois et le travail cron lirait les données via XMLRPC afin qu'il ne poursuive pas la lecture /dev/randomau démarrage.

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