Actualmente estoy probando gpg --genkeyen una máquina virtual Linux. Desafortunadamente, este software parece depender de /dev/randomla recopilación de entropía y le pide cortésmente al usuario que escriba manualmente pantalla tras pantalla 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 indicarlo. usar otro archivo como fuente de entropía (el tipoen este vídeoencuentra el mismo problema...).
Sin embargo, el usuario debe tener la libertad de elegir utilizarlo /dev/urandomya queno tiene nada de malo. Está ahí 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, mientraspágina de manual de NetBSDreconoce que la distinción aún puede ser útil en una etapa de arranque muy temprana, describe dicha distinción como"folklore"y un"teoría imaginaria que defiende sólo contra modelos de amenazas de fantasía". Nadie está de acuerdo con ninguno de los dos.la cantidad de entropía requerida por este comandoni el hecho de que la entropía sea algo que en realidad se consume como se indica enpágina de manual de GPG("POR FAVOR, no utilices este comando a menos que sepas lo que estás haciendo, ¡puede eliminar una valiosa entropía del sistema!").
he leído sobrepersonas instalando el rngddemonioy configurarlo para usarlo /dev/urandomcomo fuente de entropía para alimentar /dev/random, pero encuentro que esa práctica es muy sucia.
Intenté solucionar el problema en FreeBSD eliminándolo /dev/randomy vinculándolo a /dev/urandom:
rm /dev/random
ln -s /dev/urandom /dev/random
Veo esto como un escenario que dice"Confío /dev/urandomcomo fuente de entropía".
Temía encontrar algún tipo de error, pero esto parece proporcionar el resultado esperado ya que el comando ahora regresa exitosamente de inmediato.
Mi pregunta es:¿Existe algún efecto secundario conocido, práctico e incorrecto al vincular /dev/randomsistemas /dev/urandomLinux como se hace de forma predeterminada en los sistemas FreeBSD?¿O se podría prever establecer esto de forma permanente (en un script al final del proceso de arranque, por ejemplo) en caso de problemas repetitivos debido al /dev/randombloqueo de algún servicio?
Respuesta1
VerMitos sobre el urandom, no se conoce ningún ataque a /dev/urandom que no sea también un ataque a /dev/random. El principal problema que tiene un sistema Linux es cuando se clona y ejecuta 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.
Respuesta2
Bueno, una cosa diferente /dev/randomes que detiene la salida después de que se utiliza 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 producción. como se muestra aquí:
$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$
(Cuando intentas acceder a estos dispositivos especiales, es posible que el mensaje se confunda. Simplemente escribe resete ingresa, tu terminal volverá a la normalidad).
Úselo /dev/urandomcuando solo necesite llenar algo con un flujo constante de bits "aleatorios". Úselo /dev/randompara claves que necesita para que sean absolutamente aleatorias.
Respuesta3
En Linux, /dev/randomproporciona bits aleatorios de alta calidad. Se derivan de fuentes que sonnopredecible ynorepetible, externo a la máquina. Por el contrario, /dev/urandomutiliza los mismos datos aleatorios que /dev/random(si están disponibles), si no los hay, utiliza un generador de números pseudoaleatorios, que esdeterminista. Para la mayoría de los propósitos, es bastante impredecible, peronopara aplicaciones muy exigentes como la criptografía, y mucho menos para la creación de claves de larga duración como GPG.