Générer l'entropie pour la clé PGP


12

Je suis connecté à distance à une machine virtuelle et j'essaie de générer une clé PGP 4096 bits, elle se bloque pour toujours car il n'y a pas d'entropie et puisque je travaille via un bureau distant, il ne détecte probablement pas le mouvement de la souris comme entropie.

Comment puis-je en générer?

J'ai essayé cat /dev/urandom > /dev/nullmais ça n'aide pas.

Réponses:


13

Obtenir des données sur de /dev/randomou /dev/urandomest certainement pas aller à l' aide, tout ce qu'il va faire est épuiser votre réserve d' entropie, ce qui rend le problème encore pire. La principale différence entre ces deux fichiers est que même lorsque le noyau est à court d'entropie, urandomil continuera à générer des données aléatoires de moindre qualité, tout en randomse bloquant jusqu'à ce qu'il puisse recueillir de nouvelles données aléatoires de haute qualité. PGP nécessite les données aléatoires les plus élevées possibles pour générer des clés sécurisées, il sera donc toujours utilisé /dev/random.

Si vous avez de bonnes données aléatoires ou si vous en exportez à partir d'un autre serveur /dev/random, vous pouvez les cattransférer dans votre serveur /dev/randompour obtenir plus d'entropie. Vous ne devriez cependant jamais faire catdeux fois le même fichier /dev/random.

Si vous vous retrouvez souvent à court d'entropie, vous pouvez également envisager d'installer quelque chose comme haveged , un démon qui régénère l' entropie en arrière-plan et le remplit /dev/randomau besoin.

Il peut également être tentant d'établir un lien symbolique /dev/randomvers /dev/urandom, mais cela doit être considéré comme un risque pour la sécurité, car toute clé générée à l'aide de celle-ci peut être moins sécurisée qu'elle ne le devrait. Bien que cela puisse aider pour une application moins critique, vous devez considérer toutes les autres utilisations possibles de /dev/random, y compris les autres utilisateurs générant leurs propres clés, CSR, etc.


Notez que sur FreeBSD, /dev/randomc'est un PRNG de haute qualité , et ne devrait normalement pas se bloquer.
Kevin

@Kevin /dev/randomsont des PRNG de haute qualité sur BSD et Linux modernes, bien sûr. Mais il se bloquera s'il n'y a pas assez d'entropie disponible. D'un autre côté, /dev/urandomne bloquera pas s'il n'y en a pas assez mais sa qualité aléatoire pourrait en souffrir dans ce cas. Dans les détails, il existe de nombreuses subtilités entre les implémentations aléatoires et urandom entre Linux et les différents BSD, mais ce qui précède devrait être vrai pour tous les AFAIK.
Huygens

Sous Linux, vous pouvez générer plus d'entropie en envoyant simplement un ping à un hôte (par exemple ping 8.8.8.8) si vous possédez un autre hôte réseau, essayez d'avoir des pings toutes les 100 ms (si votre RTT est <100 ms bien sûr). Et / ou utilisez findpour rechercher des fichiers sur votre disque dur et vider le cache RAM entre chaque recherche de fichier.
Huygens

@Huygens: Ouvrez la page de manuel que j'ai liée et Ctrl + F "kern.random.sys.seeded"; par défaut, /dev/randomne bloque pas sur FreeBSD.
Kevin

1
@Kevin oui vous avez raison, la mise en commun ou la récolte d'entropie sont peut-être deux façons distinctes de "semer" le PRNG. Et après quelques tests sur ma boîte BSD, j'ai découvert que aléatoire et urandom se comportent de la même manière, ils se bloquent lorsqu'ils ne peuvent pas générer suffisamment de PRNG. Essayez d'exécuter dd if=/dev/random of=/tmp/rndtest bs=64M count=1après un nouveau démarrage, il a fallu 2 exécutions consécutives pour voir le temps de générer l'augmentation du fichier de 64 Mo. Je pensais que je ne verrais pas cet effet avec urandom en entrée, mais FreeBSD semble également le bloquer, contrairement à Linux.
Huygens


4

Je recommanderais de générer vos clés gpg sur votre machine locale qui aura un bien meilleur caractère aléatoire que celui distant. Ensuite, migrez les clés à l'aide de SSH vers votre ordinateur distant.

La génération locale sera plus rapide (plus de source d'entropie), plus sécurisée (personne ne peut espionner le processus si votre machine n'est pas infectée, meilleur hasard).

Si vous souhaitez toujours les générer à distance: sous Linux, vous pouvez générer plus d'entropie en envoyant simplement un ping à un hôte (par exemple ping 8.8.8.8) si vous possédez un autre hôte réseau, essayez d'avoir des pings toutes les 100 ms (si votre RTT est <100 ms bien sûr). Et / ou utilisez findpour rechercher des fichiers sur votre disque dur et vider le cache RAM entre chaque recherche de fichier.

Vous pouvez également installer havegedmais lire les limitations si vous l'exécutez dans un environnement virtuel: https://wiki.archlinux.org/index.php/Haveged#Virtual_machines


À mon avis, c'est la bonne solution - +1 de ma part.
MadHatter

3

Sur les systèmes basés sur Debian, vous pouvez installer le rng-toolspaquet en utilisant atp-get, puis démarrer le démon pour générer l'entropie:

echo HRNGDEVICE=/dev/urandom >> /etc/default/rng-tools && service rng-tools restart

Sur les serveurs CentOS-6, le rngdémon est installé comme l'un des outils de base (du moins sur la plupart des systèmes sur lesquels j'ai travaillé), et vous pouvez exécuter la commande suivante pour le démarrer, afin de générer l'entropie:

sed -i \'s|EXTRAOPTIONS=\"\"|EXTRAOPTIONS=\"-r /dev/urandom\"|g\' /etc/sysconfig/rngd && service rngd restart

Je ne pense pas que l'utilisation d'urandom comme source pour rngd soit intelligente. Il aidera à épuiser l'entropie disponible plus rapidement et une fois épuisé, ce sera une source biaisée pour l'entropie. J'éviterais donc cette solution.
Huygens

1
sudo yum install haveged && sudo systemctl start haveged

fonctionne certainement sur une machine virtuelle CentOS 7.2. Parfois, vous souhaitez créer des clés GPG sur un vm si vous créez un groupe et souhaitez que votre trousseau de clés soit intact.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.