/dev/random Extremadamente lento?

Question

Información básica: buscaba 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 (benchmarking operaciones de base de datos) Ejecuté algunos "head -1" en/dev/random y parecía estar funcionando bien, pero después de llamarlo un par de veces, simplemente colgaba. Después de unos minutos, finalmente emitiría un pequeño bloque de texto, luego terminaría.

Cambié a/dev/urandom (realmente no quería, es más lento y no necesito esa calidad de aleatoriedad) y funcionó bien para las dos o tres primeras llamadas, entonces también comenzó a colgar . Me preguntaba si era el comando de "cabeza" el que estaba bombardeándolo, así que intenté hacer algunas E/S simples usando Perl, y también estaba colgando. Como último esfuerzo, utilicé el comando "dd" para descargar información directamente a un archivo en lugar de a la terminal. Todo lo que pedí fue 1mb de datos, pero tardé 3 minutos en obtener ~ 400 bytes antes de matarlo.

Revisé las listas de procesos, la CPU y la memoria prácticamente no se modificaron. ¿Qué podría hacer exactamente/dev/random así y qué puedo hacer para prevenirlo/arreglarlo en el futuro?

Edit: Gracias por la ayuda chicos! Parece que tuve mezclado aleatorio y urandom. Tengo el script en funcionamiento ahora. Parece que aprendí algo nuevo hoy. :)

Answer 1

En la mayoría de los sistemas Linux, /dev/random se alimenta de la entropía real recogida por el entorno. Si su sistema no está entregando una gran cantidad de datos desde /dev/random, probablemente signifique que no está generando suficiente aleatoriedad ambiental para alimentarlo.

No estoy seguro de por qué piensas que /dev/urandom es "más lento" o de mayor calidad. Reutiliza un grupo de entropía interno para generar pseudoaleabilidad, lo que hace que su calidad sea ligeramente inferior, pero no bloquea. Generalmente, las aplicaciones que no requieren criptografía de alto nivel o de largo plazo pueden usar /dev/urandom de manera confiable.

Intente esperar un poco y luego lea de /dev/urandom nuevamente. Es posible que haya agotado el conjunto de entropía interna que lee tanto desde /dev/random, rompiendo ambos generadores, lo que permite que su sistema cree más entropía y los reponga.

Consulte Wikipedia para obtener más información sobre /dev/random y /dev/urandom.

Answer 2

Si quieres más entropía para /dev/random, entonces necesitarás comprar un hardware RNG o usar uno de los *_entropyd daemons para generarlo.

Answer 3

Si usa la aleatoriedad para las pruebas (no la criptografía), entonces la aleatoriedad repetible es mejor, puede obtener esto con pseudo aleatoriedad comenzando en 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á intentando depurar. Tampoco se traga la entropía. Puede sembrar el generador pseudo aleatorio de/dev/urandom y registrar la semilla en el registro de prueba. Perl tiene un generador de números pseudoaleatorios que puedes usar.

Answer 4

Esta pregunta es bastante antigua. Pero sigue siendo relevante, así que voy a dar mi respuesta. Muchas CPU hoy vienen con un generador de números aleatorios (RNG) de hardware 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 permitir la siembra de la TPM y el RNG CPU era:

# systemctl enable rngd 
# systemctl start rngd 

Es posible 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, necesita ser activado a través de las herramientas tpm. actualización: aquí hay un nice howto.

Por cierto, he leído en Internet que algunas preocupaciones sobre el TPM RNG a menudo se han roto de diferentes maneras, pero no he leído nada concreto contra los RNG encontrados 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 actuales usan urandom en lugar de al azar. Incluso openssl does that.

ACTUALIZACIÓN: otra opción para más entropía es HAVEGED. En las máquinas virtuales hay un kvm/qemu VirtIORNG.

Answer 5

usa/dev/urandom, es criptográficamente seguro.

buena lectura: http://www.2uo.de/myths-about-urandom/

"Si no está seguro acerca de si debe usar/dev/random o/dev/urandom, entonces probablemente usted desea utilizar el último."

En caso de duda en el inicio temprano, si tiene suficiente entropía reunida. utilice la llamada al sistema getrandom() en su lugar. [1] Lo mejor de ambos mundos, bloquea hasta (¡solo una vez!) La entropía suficiente, luego de eso nunca se bloqueará nuevamente.

[1] git kernel commit