He leído mucho sobre la distinción entre /dev/random y /dev/urandom . Entiendo que el consejo que prevalece es usar /dev/urandom . La explicación, que 256 bits de aleatoriedad "adecuada" es todo lo que necesita para casi cualquier aplicación criptográfica, tiene sentido para mí.
Un par de fuentes útiles:
- enlace
- enlace
El estado de una máquina virtual (VM) o un CD en vivo justo después del primer arranque a veces se identifica como un caso de borde inusual para esta guía, ya que /dev/urandom puede no haber sido correctamente sembrado.
En el contexto de todos los otros usos posibles de /dev/urandom , puedo ver que este es un caso de borde. Sin embargo, dado que está utilizando una VM por primera vez, parece plausible que una de las primeras cosas que podría querer hacer es llamar a /dev/urandom , por ejemplo. para generar claves SSH.
Entonces, si asumes lo peor de tu máquina virtual (por ejemplo, que fue clonada, o que después de reiniciar, los randoms recién sembrados no son buenos), ¿qué podrías hacer para asegurarte de que /dev/urandom es bueno?
Lo que hay que hacer laziest es dejar que la VM se quede ejecutando por un tiempo, hasta que eventos aleatorios hayan vuelto a sembrar el grupo de entrada. La parte incómoda es que una máquina virtual inactiva hace esto muy lentamente.
Quería probar cuánto tiempo demora esto, y traté de hacerlo de la siguiente manera:
Este comando extrae 32 bytes / 256 bits de la agrupación (y se muestra en hexadecimal)
head -c 32 </dev/random | xxd -p
Una vez que el recuento de entropía del grupo de entrada haya pasado a niveles mínimos (visibles con cat /proc/sys/kernel/random/entropy_avail ), el comando anterior se bloqueará hasta que nuevos eventos aleatorios ingresen al grupo de entrada. Eso me sugiere que si ejecutamos el comando anterior repetidamente, lo cronometramos y escribimos los resultados en un archivo llamado randomtest , indicará cuánto tiempo lleva rellenar el grupo de entrada.
Intenté escribir un comando de una línea que lo hace:
for n in {1..10}; do (/usr/bin/time -f "%E Real" sh -c 'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) >> randomtest; done
Más fácilmente:
for n in {1..10};
do (/usr/bin/time -f "%E Real" sh -c \
'printf "%-10s" $(head -c 32 </dev/random | xxd -p)' 2>&1) \
>> randomtest;
done
Sé que los procesos de inicio (incluso el comando cat anterior) reducen el grupo de entrada, por lo que esto proporcionará una estimación conservadora. Para lo que vale, dejé que el comando anterior se ejecutara en una máquina virtual inactiva, y el tiempo entre las nuevas secuencias de 32 bytes fue de 15-20 minutos cada uno.
Mis preguntas:
- ¿La salida de este comando prueba con éxito lo que creo que hace?
- ¿Existe una forma mucho más sencilla de probar lo mismo?
- ¿Existe una forma diferente / mejor 'perezosa' de actualizar el grupo de entrada y volver a generar
/dev/urandomque dejar que la VM quede inactiva?