Ajout d'une «entropie de nombres aléatoires» pour les clés GPG?

Dans la vidéo suivante: Linux HOWTO: sécurisez vos données avec PGP, partie 2 , vous apprendrez à créer une paire de clés avec gpg. À environ 1:50, l'instructeur dit ce qui suit:

Pendant la génération de la clé, c'est une bonne idée de déplacer un peu votre souris pour lui donner une entropie un peu plus aléatoire pour la création de la paire de clés.

Cela me semble être un mythe, d'autant plus que les outils de ligne de commande ne devraient généralement pas être affectés par le curseur. D'un autre côté, je n'ai aucune idée du fonctionnement du générateur de nombres aléatoires de Linux, qu'il soit partagé par l'interface graphique ou indépendant d'elle. Y a-t-il du stock dans ce qu'il prétend, ou est-ce un exemple de programmation culte du fret ?

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.

GPG utilise le générateur de nombres aléatoires Linux (noyau). Le générateur de noyau obtient l'entropie (aléatoire) de toutes sortes d'endroits, parmi lesquels le timing d'interruption, pour certaines interruptions. Déplacer la souris (et taper, activité du disque, etc.) générera tous des interruptions.

Ainsi, le déplacement de la souris alimente potentiellement le générateur de nombres aléatoires. Mais cela dépend de la version exacte du noyau utilisée; les versions plus récentes n'utilisent pas (du moins dans mes tests) des interruptions clavier ou souris pour l'entropie. L'activité du disque, cependant, le fait (ainsi, par exemple, l'exécution syncajoutera une quantité potentiellement importante d'entropie, selon la quantité nettoyée).

En bref: ce n'est pas vrai sur les versions Linux actuelles. C'était sur les plus anciens.

Cependant, si le générateur manque d’entropie, il est censé s’arrêter, donc votre génération de clés se bloquera jusqu’à ce qu’une entropie soit générée. Ce serait donc un problème éternel, pas un problème de sécurité.

Vous pouvez voir la quantité d'entropie disponible par cat /proc/sys/kernel/random/entropy_avail.

Tails a une génération de clés extrêmement rapide car il a havegedinstallé:

sudo apt-get install haveged