Solución 1:
Su sistema recopila algunos números aleatorios "reales" vigilando diferentes eventos:actividad de la red, generador de números aleatorios de hardware (si está disponible; por ejemplo, los procesadores VIA generalmente tienen un generador de números aleatorios "reales"), etc. Si los alimenta al grupo de entropía del kernel, que es utilizado por /dev/random. Las aplicaciones que necesitan seguridad extrema tienden a usar /dev/random como su fuente de entropía, o en otras palabras, la fuente de aleatoriedad.
Si /dev/random se queda sin entropía disponible, no puede ofrecer más aleatoriedad y la aplicación que espera la aleatoriedad se detiene hasta que haya más elementos aleatorios disponibles. El ejemplo que he visto durante mi carrera es que el demonio IMAP de Cyrus quería usar /dev/random para la aleatoriedad y sus sesiones POP querían generar cadenas aleatorias en conexiones APOP desde /dev/random. En un entorno ocupado, hubo más intentos de inicio de sesión que tráfico para alimentar /dev/random -> todo se estancó. En ese caso, instalé rng-tools y activé el rngd que tenía, que transportaba números semialeatorios de /dev/urandom a /dev/random en caso de que /dev/random se quedara sin entropía "real".
Solución 2:
Si desea una descripción general más simple del problema subyacente:algunas aplicaciones (como el cifrado) necesitan números aleatorios. Puede generar números aleatorios utilizando un algoritmo, pero aunque parezcan aleatorios en un sentido, son totalmente predecibles en otro. Por ejemplo, si te doy los dígitos 58209749445923078164062862089986280348253421170679, se ven bastante aleatorios. Pero si te das cuenta de que en realidad son dígitos de PI, sabrás que el siguiente será 8.
Para algunas aplicaciones, esto está bien, pero para otras aplicaciones (especialmente las relacionadas con la seguridad), la gente quiere una aleatoriedad impredecible genuina, que no puede ser generada por un algoritmo (es decir, un programa) ya que, por definición, es predecible. Este es un problema en el sentido de que su computadora esencialmente es un programa, entonces, ¿cómo es posible que obtenga números aleatorios genuinos? La respuesta es midiendo eventos genuinamente aleatorios del mundo exterior, por ejemplo, espacios entre las pulsaciones de teclas y usándolos para inyectar aleatoriedad genuina en el generador de números aleatorios predecible. El 'grupo de entropía' podría considerarse como el almacén de esta aleatoriedad que se acumula con las pulsaciones de teclas (o lo que sea que se use) y se agota con la generación de números aleatorios.
Solución 3:
La entropía es un término técnico para "aleatoriedad". Las computadoras realmente no generan entropía, sino que la recopilan observando cosas como las variaciones de las velocidades de rotación del disco duro (un fenómeno físico que es muy difícil de predecir debido a la fricción, etc.) Cuando una computadora quiere generar datos pseudoaleatorios, sembrará una fórmula matemática con entropía real que encontró al medir los clics del mouse, las variaciones de giro del disco duro, etc. En términos generales entropy_avail es la medida de bits actualmente disponibles para ser leídos desde /dev/random
A la computadora le toma tiempo leer la entropía de su entorno a menos que tenga un hardware genial como un diodo ruidoso o algo así.
Si tiene 4096 bits de entropía disponibles y cat /dev/random puede esperar poder leer 512 bytes de entropía (4096 bits) antes de que el archivo se bloquee mientras espera más entropía.
Por ejemplo, si "cat /dev/random tu entropía se reducirá a cero. Al principio, obtendrá 512 bytes de basura aleatoria, pero se detendrá y, poco a poco, verá que se filtran más datos aleatorios.
Así no es como la gente debería operar /dev/random aunque. Normalmente, los desarrolladores leerán una pequeña cantidad de datos, como 128 bits, y los usarán para generar algún tipo de algoritmo PRNG. Es educado no leer más entropía de /dev/random de lo que necesita, ya que lleva mucho tiempo construirlo y se considera valioso. Por lo tanto, si lo drena por descuido cat Al configurar el archivo como arriba, hará que otras aplicaciones necesiten leer desde /dev/random bloquear. En un sistema en el trabajo, notamos que muchas funciones criptográficas se estaban estancando. Descubrimos que un trabajo cron estaba llamando a un script de python que seguía inicializando ramdom.random() en cada ejecución que se ejecutó cada pocos segundos. Para solucionar esto, reescribimos la secuencia de comandos de Python para que se ejecutara como un demonio que se inicializaba solo una vez y el trabajo cron leía los datos a través de XMLRPC para que no siguiera leyendo desde /dev/random. al iniciar.
Solución 4:
El archivo de solo lectura entropy_avail proporciona la entropía disponible. Normalmente, serán 4096 (bits), un grupo de entropía completo.
Puede leer más en:http://linux.die.net/man/4/random