it-swarm-es.com

¿Alimentación / dev / grupo de entropía aleatorio?

¿Qué forma de alimentar adicionalmente /dev/random grupo de entropía sugeriría para producir contraseñas aleatorias? O, ¿existe quizás una mejor manera de crear localmente contraseñas totalmente aleatorias?

51
pootzko

Puede alimentarlo con ruido blanco de su chip de sonido, si está presente. Vea este artículo: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt

24
Henri

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

  • /dev/random podría ser teóricamente mejor en el contexto de un algoritmo seguro de información teóricamente . Este es el tipo de algoritmo que es seguro contra la tecnología de hoy, y también la tecnología del mañana y la tecnología utilizada por los extraterrestres, y también el propio iPad de Dios. El algoritmo teóricamente seguro de la información es seguro contra la potencia informática infinita. Huelga decir que tales algoritmos son bastante raros y si estuviera usando uno, lo sabría. Además, este es un "podría": internamente, /dev/random utiliza funciones hash convencionales, por lo que es probable que tenga debilidades de todos modos si es atacado con un poder infinito (sin embargo, no hay nada de qué preocuparse para los atacantes basados ​​en la Tierra).

  • /dev/urandom no se bloqueará, mientras que /dev/random puede hacerlo. /dev/random mantiene un contador de "cuánta entropía aún tiene" bajo el supuesto de que cualquier bit que haya producido es un bit de entropía perdido. El bloqueo provoca problemas muy reales, p. un servidor que no puede iniciarse después de una instalación automatizada 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 pseudoaleatorio criptográficamente fuerte para que no se bloquee nunca.

Entonces quieres usar /dev/urandom y deja 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 arranque (32 bytes aleatorios son suficientes). Una instalación normal de Linux creará una semilla aleatoria (de /dev/random) después de la instalación y guárdelo en el disco. En cada reinicio, la semilla se leerá y se introducirá en /dev/urandom, y una nueva semilla inmediatamente generada (de /dev/urandom) para reemplazarlo. Por lo tanto, esto garantiza que /dev/urandom siempre tendrá suficiente entropía inicial para producir alea criptográficamente fuerte, perfectamente suficiente 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 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 estará bien alimentado y no se bloqueará.

El sistema operativo en sí, y más precisamente el núcleo, está en el lugar correcto para reunir la entropía del evento de hardware, ya que maneja el hardware. Por lo tanto, hay relativamente poco que puede usar para la entropía que el kernel ya 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, generará datos con ruido térmico, y dado que genera lotes de datos , es un buen recolector de entropía. Así que solo toma algunos fotogramas de la cámara web, córtalos con una función hash segura (SHA-256) y escríbelos en /dev/urandom. Esto sigue siendo una gran exageración.

50
Thomas Pornin

Sé de daemon de entropía de audio y havege que es usado por daemon de hasged , pruébalos.

13
krempita

El mejor valor que he visto en un dispositivo de aleatoriedad HW es la clave de entropía simtec .
Tiene una serie de salvaguardas incorporadas para proteger contra fallas y ataques. Por ejemplo, ejecuta las pruebas de aleatoriedad FIPS 140-2 en cada lote de 20Kb, cerrándose si falla un número estadísticamente significativo de pruebas. Obtuve una cuando estaba haciendo muchas claves generación para la investigación de DNSSEC, y aceleró enormemente mi trabajo. Pasa todas las pruebas de dieharder (nota, siempre prueba tus secuencias de aleatoriedad periódicamente, sin importar lo que el vendedor te diga ;-)

7
spinkham

1) No necesita agregar más entropía a /dev/random, para usarlo para contraseñas. El sistema ya lo hace 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 causar que otros usuarios de /dev/random bloquear. /dev/urandom es la mejor interfaz de uso general.)

3) Aquí hay un script simple que uso para generar una contraseña aleatoria. Eres bienvenido a usarlo.

#!/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 
7
D.W.

Utilizo una combinación de fuentes de datos y un buen algoritmo de hash 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, lo que pueda recopilar), algunos datos externos (como random.org), mezcla todo con let say sha1 (mixed_data + time + some_secret_key) y obtienes bits de datos aleatorios bastante impredecibles.

También podría considerar usar P2PEG para recopilar fácilmente la entropía de los clientes y el servidor.

2
DUzun

Las contraseñas, si son cortas, siempre se pueden descifrar por la fuerza bruta si la velocidad o el recuento de intentos no están limitados. Si, por otro lado, los intentos son limitados (por ejemplo, inicio de sesión interactivo), incluso una pequeña cantidad de entropía básicamente indescifrable, 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 entropía realmente buena para las contraseñas.

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

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

1
Nakedible