Si es cierto, solo necesitas unos 128 bits de entropía para alimentar suficientes datos para siempre, ¿por qué / dev / random es tan lento? ¡Mi sistema tiene un tiempo de actividad de 214 días!
¿Realmente solo está reuniendo .000000001 bits de entropía en cada muestra? ¿No debería una simple lectura de inestabilidad del núcleo proporcionar al menos 1 bit de entropía? ¿No ha estado tomando muestras durante los últimos 214 días?
¿Se trata de un error de diseño colosal o me falta algo?
Por cierto, considero que esto es más una cuestión de seguridad de TI o sistema operativo Linux que de criptografía.
Un problema con / dev / urandom de Linux es que no es posible probar si se ha sembrado correctamente. El generador de números aleatorios puede devolver valores basados en una entropía insuficiente.
Por lo tanto, muchos recurren a / dev / random en su lugar. Sin embargo, existen diferencias significativas entre las implementaciones / dev / random en diferentes sistemas compatibles con POSIX (o clon). En FreeBSD, / dev / random funciona igual que / dev / urandom en Linux. Mac OS X es similar a FreeBSD en muchas cosas y también aquí: / dev / random es como / dev / urandom.
El objetivo de Linux / dev / random es básicamente devolver la entropía completa (un bit de salida contiene un bit de entropía). El enfoque de este objetivo es estimar la cantidad de entropía recopilada y utilizar esa estimación y el material de entropía recopilado para producir resultados. Sin el soporte de Linux, las fuentes de entropía basadas en hw disponibles, los mecanismos básicos de recolección de entropía acumularán la entropía muy lentamente.
Hay algunas formas de acelerar la recopilación de entropía, incluyendo:
Si / dev / random está vacío después de un largo tiempo de funcionamiento de la máquina, significa que algunas aplicaciones han estado utilizando los dispositivos de aleatoriedad. En Linux, / dev / random considera que se pierde la misma cantidad de entropía de la agrupación de entropía que la cantidad total de bits solicitados. (Es decir, incluso si Linux tiene 4096 bits completos en el grupo de entropía, todavía no tomará muchas solicitudes, por ejemplo, de 128 o 256 bits para agotar el grupo). Ocasionalmente, el pool se agota debido a que algunas aplicaciones abusan de / dev / random. Algunas aplicaciones pueden intentar leer grandes cantidades de datos, como 2048 bits.
En pocas palabras, debería leer la página de manual adecuada (hombre 4 al azar) y decidir si / dev / random o / dev / urandom es lo que necesita. Si el mac / dev / random estaría bien para ti, es probable que estés satisfecho con / dev / urandom. La razón por la cual la generación de números aleatorios apareció desde / dev / random mucho más rápido en Mac es que en Mac / dev / random significa algo diferente que / dev / random en Linux. Por último, pero no menos importante, me gustaría decir: me gusta el hecho de que Linux ofrece dos semánticas diferentes, sistemas operativos donde / dev / urandom y / dev / random son la misma oferta y mucho menos opciones.
Yo diría que esto no es un error colosal, el diseño es un poco extraño desde la perspectiva de muchos. Una vez que esté familiarizado con el diseño y las restricciones y sepa cómo usar los dispositivos, el diseño se sentirá bastante bien.
(Por cierto, otros sistemas como NetBSD todavía tienen una semántica un poco diferente para / dev / random y / dev / urandom.)
Lea otras preguntas en las etiquetas entropy