TL; DR:
Ninguna, de verdad. Las computadoras modernas generan entropía de alta calidad ("aleatoriedad", esencialmente) lo suficientemente rápido como para que mover el mouse sea irrelevante.
Más detalles:
Los programas como Truecrypt (y posiblemente versiones más antiguas de cosas como ssh-keygen , gpg , etc.) que le dicen que haga cosas durante la generación de claves operan en el supuesto de que el sistema operativo no tenga fuentes de entropía muy rápidas. aparte de la interacción del usuario y / o un grupo de entropía muy pequeño para su generador de números pseudoaleatorios seguro criptográficamente (CSPRNG). En las computadoras antiguas, especialmente sin conexiones a Internet o recursos suficientes para ejecutar una gran cantidad de procesos en segundo plano, esto probablemente fue cierto al menos en algunas ocasiones.
Las computadoras modernas son bastante buenas en la generación de entropía y tienen grupos de entropía relativamente grandes que pueden arrojar fácilmente pozos suficientes para generar una clave. Además, en estos días es común usar CSPRNG que admiten la entropía de estiramiento (en los sistemas operativos * nix, esta sería la diferencia entre /dev/random , que se extrae directamente del grupo de entropía, y /dev/urandom que puede tomar una pequeña cantidad de entropía del grupo y utilícelo para generar una gran cantidad de bits un poco menos aleatorios; /dev/urandom es, en sistemas operativos modernos, todavía lo suficientemente bueno para la generación de claves). Todavía es teóricamente posible terminar con máquinas que tienen grupos predecibles de entropía del kernel (un grupo de máquinas virtuales idénticas que se ejecutan en máquinas sin cabeza idénticas que ejecutan versiones de software idénticas iniciadas al mismo tiempo, etc. a veces pueden tener la misma entropía del kernel inicialmente), pero es no es fácil. Este tipo de cosas es la razón por la que los hosts de máquinas virtuales modernas tienen formas de alimentar algo de entropía a los invitados de máquinas virtuales en función de los estados de hardware, etc. que se usan habitualmente en la generación de entropía del kernel en estos días.
La mayoría de las CPU modernas tienen incluso qué cantidad de RNG de hardware basadas en cosas como el estado térmico de las diferentes partes del chip de la CPU, que varían rápidamente dependiendo de cosas como exactamente qué instrucciones se han ejecutado recientemente y si causaron errores de caché o no, variaciones minúsculas en el voltaje de la fuente de alimentación, el movimiento del aire en la habitación y otras cosas por el estilo; las diferencias son leves, pero en conjunto hay mucha entropía allí y la CPU tiene hardware dedicado para recopilarlo y nuevos códigos de operación para proporcionarlo al sistema operativo. Muchos sistemas operativos mezclan esto con su grupo de entropía del kernel, junto con otras entradas, lo que hace que sea muy difícil agotar la entropía bajo las cargas de trabajo normales de "usuario" en una PC moderna.
IMPORTANTE:
¡No hay CSRPNG en el mundo que esté sembrado en un grado significativo fuera del reloj del sistema! La razón por la cual es simple. Parece que piensas que el tiempo "hasta el milisegundo" es lo suficientemente aleatorio para el cifrado, pero estás bastante equivocado al respecto. Tomemos algo como generar un par de claves GPG como ejemplo. Los que generalmente tienen un período de validez en sus claves públicas, que me dice (tengo su clave pública, después de todo, es pública) cuando se generó la clave, hasta el día. Hay 86400000 ms en un día (ignorando el hecho de que probablemente pueda reducir eso en mucho considerando las horas en que es probable que una persona esté despierta). Log2 (86400000) tiene 26.36 bits. ¡Su par de claves RSA de 4096 bits supuestamente seguro en realidad tiene menos entropía que una contraseña de calidad decente! Los 86400000 pares diferentes de claves forzadas brutas para encontrar la clave privada correspondiente tomarán un tiempo, pero mucho menos tiempo que intentar factorizar una clave pública RSA de 4096 bits. De hecho, no hay suficientes milisegundos desde el inicio de la computación electrónica para producir una clave de DES completamente aleatoria (56 bits) al elegir entre ellos, y podemos usar el DES de fuerza bruta en menos de un día si se usan de forma estándar. hardware ( sí, la generación de claves RSA requiere mucho más trabajo que solo tomar 56 bits y calcular su paridad para la generación de claves DES, pero aún es lo suficientemente rápido para este propósito ).
En su lugar, cualquier programa criptográfico que no sea puramente basura sin valor (y algunos que lo son) usa un CSPRNG (como /dev/urandom en sistemas similares a Unix, o CryptGenRandom() en Windows) para generación de claves. De manera similar, la mayoría de las bibliotecas estándar de lenguaje de programación incluyen al menos dos PRNG: una rápida pero insegura para cosas en las que realmente no importa si alguien podría predecir teóricamente la salida (en Java, es java.util.Random ), y una seguridad criptográfica segura uno, por lo general, sembrado por o directamente devolviendo la salida del OS CSPRNG, para cosas como crypto (en Java, esto es java.security.SecureRandom ). Ningún PRNG sembrado por la hora actual, independientemente del algoritmo que use, podría considerarse criptográficamente seguro; el espacio de búsqueda es demasiado pequeño.