¿Debo usar /dev/randomo /dev/urandom?
¿En qué situaciones preferiría uno sobre el otro?
Respuestas:
Úselo /dev/urandompara la mayoría de los propósitos prácticos.
La respuesta más larga depende del sabor de Unix que esté ejecutando.
Históricamente, /dev/randomy /dev/urandomambos fueron presentados al mismo tiempo.
Como @DavidSchwartz señaló en un comentario , /dev/urandomse prefiere usar en la gran mayoría de los casos. Él y otros también proporcionaron un enlace a los excelentes mitos sobre el/dev/urandom artículo que recomiendo para leer más.
En resumen:
/dev/random bloquea cuando se queda sin entropía/dev/urandomnunca bloqueará, la lectura desde /dev/randompuede detener la ejecución de procesos./dev/urandompuede no producir una aleatoriedad de alta calidad./dev/urandomno agota el grupo de entropía (utilizado por /dev/random), sino que utiliza la salida CSPRNG del flujo ascendente./dev/urandom.Excepciones a la regla.
En la criptografía de la pila Cambio Al utilizar /dev/randommás de /dev/urandomen Linux
@otus da dos casos de uso :
Poco después del arranque en un dispositivo de baja entropía, si aún no se ha generado suficiente entropía para sembrar correctamente /dev/urandom.
Generando una plataforma única con seguridad teórica de la información
Si le preocupa (1), puede verificar 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 bloqueará , pero tenga cuidado con las posibles condiciones de carrera.
Alternativa: ¡no usar ninguno!
@otus también señaló que el getrandom()sistema leerá /dev/urandomy solo bloqueará si la entropía inicial no está disponible.
Hay problemas con el cambio /dev/urandomde usogetrandom() , pero es concebible que /dev/xrandomse cree un nuevo dispositivo basado en getrandom().
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 manera idéntica. El iOS de Apple también usa Yarrow.
No importa, como dice Wikipedia :
/dev/urandomes solo un enlace/dev/randomy solo bloquea hasta que se siembra correctamente.
Esto significa que después del arranque, FreeBSD es lo suficientemente inteligente como para esperar hasta que se haya reunido suficiente entropía de semillas antes de entregar una secuencia interminable de bondad aleatoria.
Use /dev/urandom, suponiendo que su sistema haya leído al menos una vez /dev/randompara garantizar una inicialización inicial adecuada.
La página de manual de rnd (4) dice :
/dev/urandomNunca bloquea
/dev/randomA veces bloques. Se bloqueará temprano en el arranque si se sabe que el estado del sistema es predecible.Las aplicaciones deben leer de / dev / urandom cuando necesitan datos generados aleatoriamente, por ejemplo, claves criptográficas o semillas para simulaciones.
Los sistemas deben estar diseñados para leer juiciosamente al menos una vez desde / dev / random en el arranque antes de ejecutar cualquier servicio que hable a Internet o que de otra manera requiera criptografía, para evitar generar claves de manera predecible.
/dev/urandom - Excepto que no hay tal cosa como /dev/urandomOpenBSD. OpenBSD lo ha hecho /dev/arandom, pero se supone que no debes usarlo, debes usar la arc4random(3)función en su lugar. ¿Quizás debería dejarse un consejo sobre dispositivos y funciones al azar a personas que realmente entienden de qué se trata todo esto?
/dev/randombloquea cuando se queda sin entropía" : en Linux, depende de cómo abra el dispositivo. Si las openbanderas incluyen, O_NONBLOCKentonces no se bloqueará. Si no hay entropía, la llamada volverá de inmediato e indicará 0 bytes de lectura.
/dev/randomsolo es (ej :) 60 bytes, ddle dará un archivo de 60 bytes. Usar headen el mismo escenario probablemente parecerá que está colgando para siempre. Tampoco está haciendo lo que quiere, pero, al menos para mí, es más obvio que headno está haciendo lo que se esperaba.
Tradicionalmente, la única diferencia entre /dev/urandomy /dev/randomes lo que sucede cuando el núcleo piensa que no hay entropía en el sistema: /dev/randomfalla al cerrar, /dev/urandomfalla al abrir. Los dos pilotos se abastecen de entropía add_disk_randomness(), add_interrupt_randomness()y add_input_randomness(). Ver /drivers/char/random.cpara detalles.
Editado para agregar: a partir de Linux 4.8 /dev/urandomse modificó para usar CSPRNG.
Entonces, ¿cuándo deberías fallar cerrado? Para cualquier tipo de uso criptográfico, específicamente sembrar DRBG. Hay un muy buen artículo que explica las consecuencias del uso /dev/urandomal generar claves RSA y no tener suficiente entropía. Lea Mining Your Ps and Qs .
Esta es una respuesta de "yo también", pero fortalece la recomendación de Tom Hale. Se aplica directamente a Linux.
/dev/urandom/dev/randomSegún Theodore Ts'o en la lista de correo de Linux Kernel Crypto, /dev/randomha quedado en desuso durante una década. De Re: [RFC PARCHE v12 3/4] Linux Generador de números aleatorios :
Prácticamente nadie usa / dev / random. Es esencialmente una interfaz obsoleta; Las interfaces principales que se han recomendado durante más de una década es / dev / urandom, y ahora, getrandom (2).
Probamos regularmente /dev/randomy sufre fallas frecuentes. La prueba realiza los tres pasos: (1) drenaje /dev/randomsolicitando 10K bytes en modo sin bloqueo; (2) solicite 16 bytes en modo de bloqueo (3) intente comprimir el bloque para ver si es aleatorio (prueba del pobre). La prueba tarda unos minutos en completarse.
El problema es tan grave en los sistemas Debain (i686, x86_64, ARM y MIPS) le pedimos a GCC Compile Farm que instale el rng-toolspaquete para sus máquinas de prueba. Desde Instalar rng-tools en gcc67 y gcc68 :
Me gustaría solicitar que se instalen herramientas rng en gcc67 y gcc68. Son sistemas Debian, y / dev / random sufre depleción de entropía sin herramientas rng cuando tortura las bibliotecas de prueba que utilizan el dispositivo.
Los BSD y OS X aparecen bien. El problema es definitivamente Linux.
También vale la pena mencionar que Linux no registra fallas en el generador. No querían que las entradas llenaran el registro del sistema. Hasta la fecha, la mayoría de los errores son silenciosos y la mayoría de los usuarios no los detecta.
La situación debería cambiar en breve, ya que el núcleo imprimirá al menos un mensaje de error. De [PATCH] random: silencia las advertencias del compilador y corrige la carrera en la lista de correo del kernel:
Específicamente, agregué
depends on DEBUG_KERNEL. Esto significa que estas advertencias útiles solo afectarán a otros desarrolladores de kernel. Esto es probablemente exactamente lo que queremos. Si los diversos desarrolladores asociados ven una advertencia proveniente de su subsistema particular, estarán más motivados para solucionarlo. Los usuarios ordinarios en los núcleos de distribución no deberían ver las advertencias o el correo no deseado, ya que normalmente los usuarios no usan DEBUG_KERNEL.Creo que es una mala idea suprimir todos los mensajes desde el punto de vista de la ingeniería de seguridad.
Muchas personas no ejecutan núcleos de depuración. La mayoría de los usuarios que desean o necesitan conocer los problemas no se darán cuenta de que está sucediendo. Considere, la razón por la que nos enteramos de los problemas de systemd se debió a dmesg.
La supresión de todos los mensajes para todas las configuraciones proyecta una red más amplia de la necesaria. Las configuraciones que podrían ser potencialmente detectadas y reparadas probablemente pasarán desapercibidas. Si el problema no sale a la luz, entonces no se solucionará.
Siento que el núcleo está tomando decisiones de política para algunas organizaciones. Para aquellos que tienen hardware que no se puede arreglar de manera efectiva, la organización debe decidir qué hacer en función de su adversidad de riesgo. Pueden decidir vivir con el riesgo, o pueden decidir actualizar el hardware. Sin embargo, sin información sobre el tema, es posible que ni siquiera se den cuenta de que tienen un elemento procesable.
El compromiso finalmente alcanzado más tarde en el hilo fue al menos un dmesg por módulo de llamada.