Feeding / dev / random entropy pool?

Puede alimentarlo con ruido blanco desde su chip de sonido, si está presente. Consulte este artículo: enlace

Debes usar /dev/urandom , no /dev/random . Las dos diferencias entre /dev/random y /dev/urandom son (estoy hablando de Linux aquí):

• /dev/random podría ser teóricamente mejor en el contexto de un algoritmo de información teóricamente seguro . Este es el tipo de algoritmo que es seguro contra la tecnología de hoy, y también la tecnología de mañana, y la tecnología utilizada por los alienígenas, y el propio iPad de Dios también. El algoritmo teóricamente seguro de la información es seguro contra la potencia de cálculo infinita. No hace falta decir que tales algoritmos son bastante raros y si estuvieras usando uno, lo sabrías. Además, este es un " poder ": internamente, /dev/random usa funciones hash convencionales, por lo que es probable que tenga debilidades de todos modos si fuera atacado con un poder infinito (no hay nada de qué preocuparse para los atacantes basados en la Tierra , aunque).

• /dev/urandom no se bloqueará, mientras que /dev/random puede hacerlo. /dev/random mantiene un contador de "cuánta entropía tiene todavía" bajo el supuesto de que cualquier bit que haya producido es un bit de entropía perdido. El bloqueo induce problemas muy reales, por ejemplo. un servidor que no se inicia después de una instalación automática porque se está estancando en la creación de la clave del servidor SSH (sí, lo he visto). /dev/urandom utiliza un generador de números pseudoaleatorios criptográficamente sólido para que no se bloquee nunca.

Así que quieres usar /dev/urandom y dejar de preocuparte por este negocio de entropía.

Ahora es posible que desee preocuparse por la entropía si está escribiendo el instalador de Linux. El truco es que /dev/urandom nunca bloquea, nunca, incluso cuando debería: /dev/urandom es seguro siempre que haya recibido suficientes bytes de "entropía inicial" desde el último inicio (32 bytes aleatorios son suficientes). Una instalación normal de Linux creará una semilla aleatoria (de /dev/random ) en la instalación y la guardará en el disco. Tras cada reinicio, la semilla se leerá, se alimentará en /dev/urandom y se generará una nueva semilla inmediatamente (a partir de /dev/urandom ) para reemplazarla. Por lo tanto, esto garantiza que /dev/urandom siempre tendrá suficiente entropía inicial para producir aleaciones criptográficamente sólidas, perfectamente suficientes para cualquier trabajo criptográfico mundano, incluida la generación de contraseñas. El único punto crítico es durante la instalación: el instalador debe obtener algo de entropía de /dev/random , que puede bloquear. Este problema también ocurre con el Live CD y otras variantes sin área de almacenamiento permanente de lectura y escritura. En estas situaciones, es posible que desee encontrar alguna fuente de entropía para asegurarse de que /dev/random esté bien alimentado y no se bloquee.

El sistema operativo en sí, y más precisamente el kernel, está en el lugar correcto para recopilar la entropía del evento de hardware, ya que maneja el hardware. Por lo tanto, es relativamente poco lo que puede usar para la entropía que el kernel no usa. Una de esas fuentes restantes son los datos de la cámara web: una cámara web, incluso frente a una pared en blanco, emitirá datos con ruido térmico, y dado que genera lotes de datos, es un buen recolector de entropía. Así que solo tome algunos fotogramas de la cámara web, haga un hash con una función hash segura (SHA-256) y escríbala en /dev/urandom . Esto sigue siendo una gran exageración.

Sé de demonio de entropía de audio y havege que es utilizado por haveged daemon , pruébelos.

El mejor valor que he visto en un dispositivo de aleatoriedad HW es la clave de entropía simtec.
Tiene una serie de protecciones integradas para proteger contra fallos y ataques. Por ejemplo, ejecuta las pruebas de aleatoriedad FIPS 140-2 en cada lote de 20Kb, y se apaga si falla una cantidad estadísticamente significativa de pruebas. Obtuve una cuando estaba haciendo mucha generación de claves para la investigación de DNSSEC, y aceleró enormemente mi trabajo. Pasa todas las pruebas más duras. (tenga en cuenta que siempre pruebe sus flujos de aleatoriedad periódicamente, sin importar lo que le diga el proveedor ;-)

1) No es necesario agregar más entropía a / dev / random, para usarlo para contraseñas. El sistema ya hace eso por ti.

2) Para generar una contraseña aleatoria, es mejor usar / dev / urandom, no / dev / random. (/ dev / random tiene algunos problemas: bloquea, agota el grupo de entropía de una manera que puede hacer que otros usuarios de / dev / random bloqueen. / dev / urandom es la mejor interfaz de uso general.)

3) Aquí hay un script simple que uso para generar una contraseña aleatoria. Le invitamos a utilizarlo.

#!/bin/sh
# Make a 48-bit password (8 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-11 

Uso una combinación de fuentes de datos y un buen algoritmo de hashing para generar datos aleatorios.

En un servidor web puede combinar datos del servidor (HW, SW, rendimiento), datos del cliente (agente de usuario, tiempo de solicitud, cookie, variables de URL, cualquier cosa que pueda recopilar), algunos datos externos (como aleatorios). org), mezcle todo con digamos sha1 (mixed_data + time + some_secret_key) y obtendrá bits de datos aleatorios bastante impredecibles.

También puede considerar el uso de P2PEG para recoger fácilmente la entropía de los clientes y el servidor.

Las contraseñas, si son cortas, siempre son craqueables por fuerza bruta si la velocidad o el conteo de intentos no están limitados. Si, por otro lado, los intentos son limitados (p. Ej., Inicio de sesión interactivo), incluso una pequeña cantidad de entropía básicamente no se puede rastrear: la cantidad de intentos requeridos se vuelve prohibitiva muy pronto.

Por lo tanto, no debería haber casos en los que sea importante obtener una buena entropía para las contraseñas.

Así que solo usa / dev / urandom, es más que suficiente.

Las otras respuestas que se dan aquí son buenos comentarios sobre cómo mantener su / dev / random con suficiente entropía, sin embargo, si lo necesita.

GUChaos.c recupera números aleatorios de al azar. org , y los cambia sobre la marcha a través de un cifrado de sustitución antes de alimentar a /dev/random .

Es extraño ver un montón de recomendaciones para usar / dev / urandom en lugar de usar / dev / random porque cuando / dev / random se agota, entonces / dev / urandom usa repetidamente la última entropía, lo que es sumamente inseguro para los críticos a largo plazo parámetros.