¿Cuándo usar /dev/random Vs /dev/urandom?

¿Debería usar /dev/random? o /dev/urandom ?

¿En qué situaciones preferiría una sobre la otra?

Respuesta aceptada:

TL;DR

Utilice /dev/urandom para la mayoría de los propósitos prácticos.

La respuesta más larga depende del sabor de Unix que esté ejecutando.

Linux

Históricamente, /dev/random y /dev/urandom se introdujeron al mismo tiempo.

Como señaló @DavidSchwartz en un comentario, usando /dev/urandom se prefiere en la gran mayoría de los casos. Él y otros también proporcionaron un enlace a los excelentes Mitos sobre /dev/urandom artículo que recomiendo para leer más.

En resumen:

• La página de manual es engañosa.
• Ambos son alimentados por el mismo CSPRNG para generar aleatoriedad (diagramas 2 y 3)
• /dev/random se bloquea cuando se queda sin entropía,
  así que lee desde /dev/random puede detener la ejecución del proceso.
• La cantidad de entropía se estima de forma conservadora, pero no se cuenta
• /dev/urandom nunca bloqueará.
• En casos excepcionales, muy poco tiempo después del arranque, es posible que el CSPRNG no haya tenido suficiente entropía para sembrar correctamente y /dev/urandom puede no producir aleatoriedad de alta calidad.
• La baja entropía no es un problema si el CSPRNG se sembró inicialmente correctamente.
• El CSPRNG se vuelve a sembrar constantemente.
• En Linux 4.8 y posteriores, /dev/urandom no agota el grupo de entropía (utilizado por /dev/random ) pero usa la salida CSPRNG de upstream.
• Utilice /dev/urandom .

Excepciones a la regla

En Cryptography Stack Exchange's When to use /dev/random sobre /dev/urandom en Linux @otus da dos casos de uso:

1. Poco después del arranque en un dispositivo de baja entropía, si aún no se ha generado suficiente entropía para inicializar correctamente /dev/urandom .

2. Generando un one-time pad con seguridad teórica de la información

Si te preocupa (1), puedes comprobar la entropía disponible en /dev/random .

Si estás haciendo (2) ya lo sabrás 🙂

Nota:puede verificar si la lectura de /dev/random se bloqueará, pero tenga cuidado con las posibles condiciones de carrera.

Alternativa:¡no usar ninguno!

@otus también señaló que getrandom() el sistema leerá desde /dev/urandom y solo bloquee si la entropía semilla inicial no está disponible.

Hay problemas con el cambio de /dev/urandom usar getrandom() , pero es concebible que un nuevo /dev/xrandom el dispositivo se crea en base a getrandom() .

macOS

No importa, como dice Wikipedia:

macOS usa Yarrow de 160 bits basado en SHA1. No hay diferencia entre /dev/random y /dev/urandom; ambos se comportan de forma idéntica. iOS de Apple también usa Yarrow.

BSD gratuito

No importa, como dice Wikipedia:

/dev/urandom es solo un enlace a /dev/random y solo bloques hasta que estén bien sembrados.

Esto significa que después del arranque, FreeBSD es lo suficientemente inteligente como para esperar hasta que se haya reunido suficiente entropía inicial antes de entregar un flujo interminable de bondad aleatoria.

Relacionado:Linux:¿cómo hacer que Oracle java 7 funcione con setcap cap_net_bind_service+ep?

NetBSD

Utilice /dev/urandom , suponiendo que su sistema haya leído al menos una vez de /dev/random para garantizar una siembra inicial adecuada.

La página de manual de rnd(4) dice:

/dev/urandom nunca bloquea.

/dev/random a veces bloques. Se bloqueará temprano en el arranque si se sabe que el estado del sistema
es predecible.

Las aplicaciones deben leer desde /dev/urandom cuando necesitan datos generados aleatoriamente
, p. claves criptográficas o semillas para simulaciones.

Los sistemas deben diseñarse para leer juiciosamente al menos una vez desde /dev/random en el arranque antes de ejecutar cualquier servicio que se comunique con
Internet o que requiera criptografía, para evitar
generar claves de manera predecible.