linux - online - / dev/random extremadamente lento?
linux terminal slant (5)
Alguna información de fondo: estaba buscando ejecutar un script en un servidor de Red Hat para leer algunos datos de / dev / random y usar el comando Perl unpack () para convertirlo en una cadena hexadecimal para su uso posterior (operaciones de bases de datos de referencia). Corrí unos cuantos "head -1" en / dev / random y parecía estar funcionando bien, pero después de llamarlo unas cuantas veces, simplemente se colgaba. Después de unos minutos, finalmente generaría un pequeño bloque de texto y luego terminaría.
Cambié a / dev / urandom (realmente no quería hacerlo, es más lento y no necesito esa calidad de aleatoriedad) y funcionó bien durante las primeras dos o tres llamadas, entonces también comenzó a colgarse. Me preguntaba si era el comando "cabeza" el que lo estaba bombardeando, así que intenté hacer una E / S simple usando Perl, y también estaba colgado. Como último esfuerzo de zanja, usé el comando "dd" para volcar algo de información directamente en un archivo en lugar de en el terminal. Todo lo que pedí fue 1 MB de datos, pero tardé 3 minutos en obtener ~ 400 bytes antes de que lo matara.
Revisé las listas de procesos, la CPU y la memoria estaban básicamente intactas. ¿Qué podría causar exactamente que / dev / random cague así y qué puedo hacer para prevenirlo / arreglarlo en el futuro?
Edit: Gracias por la ayuda chicos! Parece que tuve aleatoria y urandom confundido. Tengo el script en funcionamiento ahora. Parece que aprendí algo nuevo hoy. :)
En la mayoría de los sistemas Linux, /dev/random se alimenta de la entropía real recopilada por el entorno. Si su sistema no entrega una gran cantidad de datos de /dev/random , probablemente significa que no está generando suficiente aleatoriedad ambiental para alimentarlo.
No estoy seguro de por qué crees que /dev/urandom es "más lento" o de mayor calidad. Reutiliza un grupo de entropía interno para generar pseudoaleabilidad, lo que lo hace de una calidad ligeramente inferior, pero no se bloquea. En general, las aplicaciones que no requieren criptografía de alto nivel o de largo plazo pueden usar /dev/urandom forma confiable.
Intente esperar un poco y luego vuelva a leer desde /dev/urandom . Es posible que hayas agotado la lectura de la agrupación de entropía interna desde /dev/random , rompiendo ambos generadores, lo que permite que tu sistema cree más entropía para reponerlos.
Consulte wiki para obtener más información sobre /dev/random y /dev/urandom .
Esta pregunta es bastante antigua. Pero sigue siendo relevante así que voy a dar mi respuesta. Muchas CPU hoy en día vienen con un generador de números aleatorios de hardware (RNG) incorporado. Además, muchos sistemas vienen con un módulo de plataforma confiable (TPM) que también proporciona un RNG. También hay otras opciones que se pueden comprar, pero es probable que su computadora ya tenga algo.
Puede usar rngd del paquete rng-utils en la mayoría de las distribuciones de Linux para generar más datos aleatorios. Por ejemplo, en fedora 18, todo lo que tenía que hacer para habilitar la siembra desde el TPM y la CPU RNG (instrucción RDRAND) era:
# systemctl enable rngd
# systemctl start rngd
Puedes comparar la velocidad con y sin rngd. Es una buena idea ejecutar rngd -v -f desde la línea de comandos. Eso te mostrará las fuentes de entropía detectadas. Asegúrese de que todos los módulos necesarios para soportar sus fuentes estén cargados. Para usar TPM, debe activarse a través de las herramientas tpm. actualización : aquí hay un buen howto .
Por cierto, he leído en Internet algunas preocupaciones sobre la ruptura de TPM RNG a menudo de diferentes maneras, pero no leí nada concreto contra los RNG que se encuentran en los chips Intel, AMD y VIA. Usar más de una fuente sería mejor si realmente te importa la calidad de la aleatoriedad.
AFAIK urandom está bien para la mayoría de los casos de uso. La mayoría de los programas hoy en día utilizan urandom en lugar de al azar. Incluso openssl hace eso .
ACTUALIZACIÓN: otra opción para más entropía es HAVEGED (calidad cuestionada). En las máquinas virtuales hay un kvm / qemu VirtIORNG (recomendado).
Si desea más entropía para /dev/random , deberá comprar un RNG de hardware o usar uno de los daemons * _entropyd para generarlo.
Si está utilizando la aleatoriedad para las pruebas (no la criptografía), entonces la aleatoriedad repetible es mejor, puede obtener esto con una pseudo aleatoriedad a partir de una semilla conocida. Generalmente hay una buena función de biblioteca para esto en la mayoría de los idiomas.
Es repetible, para cuando encuentra un problema y está tratando de depurar. Tampoco se come la entropía. Puede sembrar el generador pseudoaleatorio de / dev / urandom y registrar la semilla en el registro de prueba. Perl tiene un generador de números pseudoaleatorios que puedes usar.
usar / dev / urandom, es criptográficamente seguro.
buena lectura: 2uo.de/myths-about-urandom
"Si no está seguro de si debe usar / dev / random o / dev / urandom, entonces probablemente quiera usar este último".
En caso de duda en el inicio temprano, si tiene suficiente entropía reunida. Utilice el sistema de llamada getrandom() lugar. [1] Lo mejor de ambos mundos,
- bloquea hasta que (¡solo una vez!) se acumula suficiente entropía,
- después de eso nunca volverá a bloquear.