Hay un grano de verdad en esto, de hecho más verdad que mito, pero no obstante, la declaración refleja un malentendido fundamental de lo que está sucediendo. Sí, mover el mouse mientras se genera una clave con GPG puede ser una buena idea. Sí, mover el mouse contribuye con una entropía que hace que los números aleatorios sean aleatorios. No, mover el mouse no hace que la clave sea más segura.
Todos los buenos generadores aleatorios adecuados para la criptografía, y Linux está en esa categoría, tienen dos componentes:
- Una fuente de entropía , que no es determinista. El propósito de la entropía es arrancar el generador de números aleatorios con datos impredecibles. La fuente de entropía debe ser no determinista: de lo contrario, un adversario podría reproducir el mismo cálculo.
- Un generador de números pseudoaleatorios , que produce números aleatorios impredecibles de manera determinista a partir de un estado interno cambiante.
La entropía debe provenir de una fuente externa a la computadora. El usuario es una fuente de entropía. Lo que el usuario hace en su mayoría no es aleatorio, pero la sincronización precisa de las pulsaciones de teclas y los movimientos del mouse es tan impredecible que puede ser ligeramente aleatoria, no muy aleatoria, pero poco a poco se acumula. Otras fuentes potenciales de entropía incluyen la sincronización de los paquetes de red y el ruido blanco de la cámara o el micrófono. Las diferentes versiones y configuraciones de kernel pueden usar un conjunto diferente de fuentes. Algunas computadoras tienen circuitos RNG de hardware dedicados basados en la desintegración radiactiva o, menos impresionantemente, en circuitos electrónicos inestables. Estas fuentes dedicadas son especialmente útiles en dispositivos y servidores integrados que pueden tener un comportamiento bastante predecible en su primer arranque, sin que un usuario haga cosas raras.
Linux proporciona números aleatorios a los programas a través de dos dispositivos: /dev/randomy/dev/urandom . La lectura desde cualquier dispositivo devuelve calidad criptográfica. Ambos dispositivos usan el mismo estado RNG interno y el mismo algoritmo para transformar el estado y producir bytes aleatorios. Tienen limitaciones peculiares que no hacen que ninguno de ellos sea lo correcto:
/dev/urandom puede devolver datos predecibles si el sistema aún no ha acumulado suficiente entropía./dev/randomcalcula la cantidad de entropía disponible y bloques si no hay suficiente. Esto suena bien, excepto que el cálculo se basa en consideraciones teóricas que hacen que la cantidad de entropía disponible disminuya linealmente con cada bit de salida. Por lo tanto, /dev/randomtiende a bloquearse muy rápidamente.
Los sistemas Linux guardan el estado interno RNG en el disco y lo restauran en el momento del arranque. Por lo tanto, la entropía se transfiere de una bota a la siguiente. El único momento en que un sistema Linux puede carecer de entropía es cuando está recién instalado. Una vez que hay suficiente entropía en el sistema, la entropía no disminuye; solo el cálculo defectuoso de Linux disminuye. Para obtener más explicaciones de esta consideración, leer /dev/urandomes adecuado para generar una clave criptográfica , por un criptógrafo profesional. Vea aso ¿Puede explicar la estimación de entropía utilizada en random.c .
Mover el mouse agrega más entropía al sistema. Pero gpg solo puede leer /dev/random, no/dev/urandom (una forma de resolver este problema es hacer /dev/randomel mismo dispositivo 1: 9 que /dev/urandom), por lo que nunca corre el riesgo de recibir números aleatorios no aleatorios. Si no mueve el mouse, la tecla es tan aleatoria como puede ser; pero lo que puede suceder es que gpg puede bloquearse en una lectura /dev/random, esperando que el contador de entropía del núcleo aumente.