linux - ¿Entendí/dev/urandom?

unix cryptography (3)

He estado leyendo sobre /dev/urandom , y hasta donde puedo decir, /dev/random crea números criptográficos al azar aprovechando varios eventos como los tiempos de paquetes de red, etc. Sin embargo, entendí bien que /dev/urandom usa un PRNG, sembrado con un número de /dev/random ? ¿O simplemente usa /dev/random siempre que haya bits, y cuando se agotan, vuelve a caer en algún PRNG con una semilla recolectada de dónde?

Citando here

/dev/random se bloqueará después de que se agote el pool de entropía. Permanecerá bloqueado hasta que se hayan recopilado datos adicionales de las fuentes de entropía disponibles. Esto puede ralentizar la generación de datos aleatorios.
/dev/urandom no bloqueará. En su lugar, reutilizará el grupo interno para producir más bits pseudoaleatorios.

/dev/urandom se usa mejor cuando:

Solo desea un archivo grande con datos aleatorios para algún tipo de prueba.
Está utilizando el comando dd para borrar datos de un disco reemplazándolo con datos aleatorios.
Casi en todas partes, donde no tienes una muy buena razón para usar /dev/random lugar.

/dev/random es probable que sea la mejor opción cuando:

La aleatoriedad es fundamental para la seguridad de la criptografía en su aplicación: pads únicos, generación de claves.

De la página de urandom :

El generador de números aleatorios reúne el ruido ambiental de los controladores de dispositivos y otras fuentes en un conjunto de entropía. El generador también mantiene una estimación de la cantidad de bits de ruido en el grupo de entropía. A partir de este grupo de entropía, se crean números aleatorios.
Cuando se lee, el dispositivo / dev / random solo devolverá bytes aleatorios dentro del número estimado de bits de ruido en el grupo de entropía. / dev / random debe ser adecuado para usos que requieren una aleatoriedad de muy alta calidad, como la generación de un pad o llave de una sola vez. Cuando el grupo de entropía está vacío, las lecturas de / dev / random se bloquearán hasta que se recopile ruido ambiental adicional.
Una lectura del dispositivo / dev / urandom no bloqueará la espera de más entropía . Como resultado, si no hay suficiente entropía en el conjunto de entropía, los valores devueltos son teóricamente vulnerables a un ataque criptográfico en los algoritmos utilizados por el controlador. El conocimiento de cómo hacer esto no está disponible en la literatura actual no clasificada, pero es teóricamente posible que tal ataque pueda existir. Si esto es una preocupación en su aplicación, use / dev / random en su lugar.

ambos usan un PRNG, aunque el uso de datos ambientales y el pool de entropía hace que sea astronómicamente mucho más difícil de descifrar el PRNG, y es imposible sin recopilar exactamente los mismos datos ambientales.

Como regla general, sin hardware costoso especializado que recopile datos de, por ejemplo, eventos cuánticos, no existe el generador de números aleatorios verdadero (es decir, un RNG que genera un número verdaderamente impredecible); aunque con fines criptográficos, / dev / random o / dev / urandom serán suficientes (el método utilizado es para un CPRNG, generador de números pseudoaleatorios criptográficos).

El conjunto de entropía y la lectura de bloqueo de / dev / random se usa como salvaguarda para asegurar la imposibilidad de predecir el número aleatorio; si, por ejemplo, un atacante agotó el conjunto de entropía de un sistema, es posible, aunque muy improbable con la tecnología actual, predecir la salida de / dev / urandom que no se ha resembrado durante mucho tiempo (aunque eso también requeriría que el atacante agote la capacidad del sistema para recolectar más entropías, lo que también es astronómicamente improbable).

En realidad, lo que necesita en la práctica es lo que proporciona /dev/urandom FreeBSD: leerá una semilla inicial de suficiente longitud desde /dev/random , luego usará un PRNG. Por lo tanto, puede bloquearse inicialmente (justo después del inicio del sistema) pero una vez que ha reunido suficiente entropía, nunca se bloquea. Esto proporciona el nivel de aleatoriedad que necesitan la mayoría de los protocolos criptográficos, aunque no bloquea excesivamente.

El /dev/urandom Linux es similar, excepto que nunca se bloqueará y, por lo tanto, se corre el riesgo de devolver la aleatoriedad de baja calidad si se usa justo después del arranque. Por otro lado, /dev/random puede bloquearse incluso después del tiempo de arranque, lo que también es un problema. A menudo he visto servidores atascados misteriosamente, porque algunos programas de software insistían en usar /dev/random , y el servidor sin teclado no obtenía suficiente entropía.

Distribución habitual de Linux guarde en el cierre una semilla aleatoria obtenida de /dev/urandom , e inyéctela nuevamente en el próximo arranque, garantizando así la calidad del azar proporcionado por /dev/urandom . Solo durante la instalación del sistema operativo la calidad criptográfica se convierte en un problema, y generalmente no se debe a que la instalación implique una serie de interacciones con el ser humano que realiza la instalación, generando hordas de entropía.

En resumen, tanto en Linux como en FreeBSD, debe usar /dev/urandom , no /dev/random .