¿Está mal vincular / dev / random a / dev / urandom en Linux?

Actualmente estoy probando gpg --genkeyen una máquina virtual Linux. Desafortunadamente, este software parece depender /dev/randomde la recopilación de entropía y educadamente le pide al usuario que escriba manualmente las pantallas después de las pantallas de entrada criptográficamente aleatoria para que eventualmente termine generando una clave, y no he encontrado ningún parámetro de línea de comando para contar usar otro archivo como fuente de entropía (el tipo en este video encuentra el mismo problema ...).

Sin embargo, el usuario debe ser libre de elegir usarlo, /dev/urandomya que no tiene nada de malo . Está allí principalmente como una reminiscencia de los algoritmos PRNG más antiguos que eran más débiles desde el punto de vista criptográfico. Por ejemplo, si bien la página de manual de NetBSD garantiza que la distinción aún puede ser útil en una etapa de arranque muy temprana, describe tal distinción como "folklore" y una "teoría imaginaria que defiende solo contra los modelos de amenaza de fantasía" . Nadie está de acuerdo con la cantidad de entropía requerida por este comando ni con el hecho de que la entropía es algo que en realidad se consume como se indica en la página de manual de GPG ("¡POR FAVOR, no use este comando a menos que sepa lo que está haciendo, puede eliminar la entropía preciosa del sistema!" )

He leído acerca de las personas que instalan el rngddemonio y lo configuran para usarlo /dev/urandomcomo fuente de entropía para alimentarse /dev/random, pero encuentro esa práctica muy sucia.

Intenté solucionar el problema en la forma de FreeBSD quitándolo /dev/randomy vinculándolo a /dev/urandom:

rm /dev/random
ln -s /dev/urandom /dev/random

Veo esto como una configuración que dice "Confío /dev/urandomcomo fuente de entropía" .

Temía encontrar algún error de algún tipo, pero esto parece proporcionar el resultado esperado ya que el comando ahora regresa con éxito inmediatamente.

Mi pregunta es: ¿hay alguna conocida, práctico y el mal efecto secundario de vincular /dev/randoma /dev/urandomen sistemas Linux como se hace por defecto en sistemas FreeBSD? ¿O podría preverse establecer esto permanentemente (en un script al final del proceso de arranque, por ejemplo) en caso de problemas repetitivos debido al /dev/randombloqueo de algún servicio?

Vea Mitos sobre urandom , no hay un ataque conocido en / dev / urandom que no sea también un ataque en / dev / random. El principal problema que tiene un sistema Linux es cuando se clona y ejecuta como varias máquinas virtuales sin restablecer el grupo de entropía guardado después de la clonación. Ese es un caso de esquina tangencial a lo que quieres.

Bueno, una cosa diferente /dev/randomes que detiene la salida después de que se usa el grupo de entropía. prueba esto:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomsin embargo, reutilizará el mismo grupo para continuar con la salida. como se muestra aquí:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Cuando intente capturar estos dispositivos especiales, su mensaje podría estar en mal estado. Simplemente escriba resete ingrese, su terminal volverá a la normalidad)

Úselo /dev/urandomcuando solo necesite llenar algo con un flujo constante de bits "aleatorios". Use /dev/randompara claves que necesita ser absolutamente al azar.

En Linux, /dev/randomproporciona bits aleatorios de alta calidad. Se derivan de fuentes que no son predecibles ni repetibles, externas a la máquina. Por el contrario, /dev/urandomusa los mismos datos aleatorios que /dev/random(si están disponibles), si no hay ninguno, usa un generador de números pseudoaleatorios, que es determinista . Para la mayoría de los propósitos, es lo suficientemente impredecible, pero no para aplicaciones muy exigentes como la criptografía, y mucho menos para crear claves de larga duración como GPG.