Il y a un grain de vérité à cela, en fait plus de vérité que de mythe, mais néanmoins la déclaration reflète une incompréhension fondamentale de ce qui se passe. Oui, déplacer la souris tout en générant une clé avec GPG peut être une bonne idée. Oui, le déplacement de la souris contribue à l'entropie qui rend les nombres aléatoires aléatoires. Non, déplacer la souris ne sécurise pas la clé.
Tous les bons générateurs aléatoires adaptés à la cryptographie, et Linux est dans cette catégorie, ont deux composants:
- Une source d' entropie , qui n'est pas déterministe. Le but de l'entropie est d'amorcer le générateur de nombres aléatoires avec des données imprévisibles. La source d'entropie doit être non déterministe: sinon, un adversaire pourrait reproduire le même calcul.
- Un générateur de nombres pseudo-aléatoires , qui produit des nombres aléatoires imprévisibles de façon déterministe à partir d'un état interne changeant.
L'entropie doit provenir d'une source externe à l'ordinateur. L'utilisateur est une source d'entropie. Ce que l'utilisateur fait n'est généralement pas aléatoire, mais le timing fin des frappes et des mouvements de la souris est si imprévisible qu'il est légèrement aléatoire - pas très aléatoire, mais petit à petit, il s'accumule. D'autres sources potentielles d'entropie incluent la synchronisation des paquets réseau et le bruit blanc de la caméra ou du microphone. Différentes versions et configurations du noyau peuvent utiliser un ensemble différent de sources. Certains ordinateurs ont des circuits RNG matériels dédiés basés sur la désintégration radioactive ou, moins impressionnant, des circuits électroniques instables. Ces sources dédiées sont particulièrement utiles dans les appareils et serveurs intégrés qui peuvent avoir un comportement assez prévisible lors de leur premier démarrage, sans qu'un utilisateur ne fasse des choses étranges.
Linux fournit des nombres aléatoires aux programmes via deux appareils: /dev/randomet/dev/urandom . La lecture de l'un ou l'autre appareil renvoie une qualité cryptographique. Les deux appareils utilisent le même état RNG interne et le même algorithme pour transformer l'état et produire des octets aléatoires. Ils ont des limitations particulières qui ne font ni l'un ni l'autre la bonne chose:
/dev/urandom peut renvoyer des données prévisibles si le système n'a pas encore accumulé une entropie suffisante./dev/randomcalcule la quantité d'entropie disponible et bloque s'il n'y en a pas assez. Cela semble bon, sauf que le calcul est basé sur des considérations théoriques qui font que la quantité d'entropie disponible diminue linéairement avec chaque bit de sortie. A donc /dev/randomtendance à se bloquer très rapidement.
Les systèmes Linux enregistrent l'état RNG interne sur le disque et le restaurent au démarrage. Par conséquent, l'entropie se poursuit d'une botte à l'autre. Le seul moment où un système Linux peut manquer d'entropie est lorsqu'il est fraîchement installé. Une fois qu'il y a suffisamment d'entropie dans le système, l'entropie ne diminue pas; seul le calcul imparfait de Linux diminue. Pour plus d'explications sur cette considération, read /dev/urandomconvient pour générer une clé cryptographique , par un cryptographe professionnel. Voir aussi Pouvez-vous expliquer l'estimation de l'entropie utilisée dans random.c .
Déplacer la souris ajoute plus d'entropie au système. Mais gpg ne peut lire que depuis /dev/random, pas/dev/urandom (un moyen de résoudre ce problème est de créer /dev/randomle même appareil 1: 9 que /dev/urandom), il n'est donc jamais à risque de recevoir des nombres aléatoires pas assez aléatoires. Si vous ne déplacez pas la souris, la clé est aussi aléatoire que possible; mais ce qui peut arriver, c'est que gpg peut être bloqué dans une lecture de /dev/random, en attendant que le compteur d'entropie du noyau augmente.