/dev/random Extremadamente lento?

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./dev/random Extremadamente lento?

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. :)

Fuente

2011-01-27 Mr. Llama

Parece que tienes los 2 dispositivos de mezclado; en un sistema Linux,/dev/random es el dispositivo aleatorio de bloqueo de alta calidad. Se "colgará" cuando no haya más entropía recolectada disponible para generar números aleatorios de alta calidad./dev/urandom debe ser no bloqueante y pseudoaleatorio. – geoffspear

Con respecto a '/ dev/random', consulte [wiki] (http://en.wikipedia.org/wiki//dev/random):" Cuando el grupo de entropía está vacío, las lecturas de/dev/random se bloquearán hasta que se recolecta ruido ambiental ". '/ dev/urandom' debería ser no bloqueante, ¿está seguro de haberlo usado? – delnan

como un lado, ejecutaste 'cabeza -1', esto tendrá el efecto de leer una línea, es decir. lea hasta que encuentre una nueva línea. si intenta leer una pequeña cantidad de datos, probablemente debería usar 'dd' en su lugar. – Hasturkun

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.

Fuente

2011-01-27 17:04:38 Tim

Ah, parece que he confundido cuál de las dos no se considera segura para el uso criptográfico. Si escribo en/dev/random (para mezclar datos aleatorios adicionales), ¿ayudaría esto a resolver el problema y qué "retorno de inversión" obtendría? (Por ejemplo, si escribo en 1MB de datos, ¿cuántos MB de lectura tendré garantizados para salir de él, o incluso ese es el caso?) –

@GigaWatt: Eso realmente depende de cuántos bits de entropía tenga el sistema obtiene de sus escritos.Esto también será bastante inútil a menos que poseas una mejor fuente de entropía que '/ dev/random', en cuyo caso probablemente deberías dejar que el kernel maneje esa fuente de entropía en primer lugar – Hasturkun

@GigaWatt: sí, puedes escribir/dev/random pero eso no ayudaría porque no estarías llamando a la llamada ioctl para aumentar la entropía e incluso si obtienes datos aleatorios de mayor calidad, no será más rápido. Lea sobre rngd. – akostadinov

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.

Fuente

2011-01-27 17:05:37

generar entropía es un problema difícil. Es más seguro para los usuarios (cualquiera sin un profundo conocimiento criptográfico) evitar el cambio del mecanismo predeterminado. Mejor pegar '/ dev/urandom' como se explica aquí http://www.2uo.de/myths-about-urandom/ – akostadinov

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.

Fuente

2012-05-29 21:17:48

'/dev/random' es el mismo pseudogenerador como 'urandom' ver http: // www. 2uo.de/myths-about-urandom/ – akostadinov

@akostadinov El artículo dice que '/ dev/random' puede bloquear. Aso it y '/ dev/urandom' son, como se dice, impredecibles. Por lo tanto, como dije irrepetible, tan pobre para probar. –

'/ dev/(u) random' es un generador de números pseudoaleatorio. La predictibilidad y la repetibilidad son propiedades diferentes. Simplemente te faltan los controles de kernel necesarios para que sean predecibles y repetibles (y gracias a Dios por eso). Estoy de acuerdo en que otros generadores son mejores para escenarios de prueba particulares. Su respuesta, debo estar de acuerdo, da un consejo razonable para el caso de uso particular. Pero SO no me permitirá revertir mi voto hasta que se edite la respuesta. Lo cual sería bueno de todos modos. – akostadinov

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.

Fuente

2013-02-08 16:10:13 akostadinov

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

Fuente

2015-01-14 15:10:45 harmv

¿Por qué fue esta respuesta downvoted? Parece una buena respuesta para mí ... pero tal vez me esté perdiendo el problema. – MountainX

Respuesta

Cuestiones relacionadas