Je teste actuellement gpg --genkey
sur une machine virtuelle Linux. Malheureusement, ce logiciel semble s'appuyer sur /dev/random
pour recueillir l'entropie et demande poliment à l'utilisateur de taper manuellement les écrans après les écrans de saisie cryptographique aléatoire afin qu'il finisse par générer une clé, et je n'ai trouvé aucun paramètre de ligne de commande à dire pour utiliser un autre fichier comme source d'entropie (le gars sur cette vidéo rencontre le même problème ...).
Cependant, l'utilisateur devrait être libre de choisir d'utiliser à la /dev/urandom
place, car il n'y a rien de mal à cela . Il s'agit principalement d'une réminiscence d'algorithmes PRNG plus anciens qui étaient plus faibles d'un point de vue cryptographique. Par exemple, alors que la page de manuel de NetBSD admet que la distinction peut encore être utile à un stade de démarrage très précoce, elle décrit une telle distinction comme "folklore" et "théorie imaginaire qui ne défend que contre les modèles de menace fantaisistes" . Personne n'est d'accord avec la quantité d'entropie requise par cette commande ni avec le fait que l'entropie est quelque chose qui est réellement consommé comme indiqué dans la page de manuel GPG ("S'IL VOUS PLAÎT, n'utilisez pas cette commande à moins que vous sachiez ce que vous faites, cela pourrait supprimer une entropie précieuse du système!" ).
J'ai lu des informations sur les gens qui installent le rngd
démon et le configurent pour l'utiliser /dev/urandom
comme source d'entropie pour alimenter /dev/random
, mais je trouve une telle pratique très sale.
J'ai essayé de contourner le problème de la manière FreeBSD en le supprimant /dev/random
et en le liant à la /dev/urandom
place:
rm /dev/random
ln -s /dev/urandom /dev/random
Je vois cela comme un paramètre indiquant "Je fais confiance en /dev/urandom
tant que source d'entropie" .
Je craignais de rencontrer une erreur quelconque, mais cela semble fournir le résultat attendu puisque la commande revient maintenant avec succès immédiatement.
Ma question est la suivante: y a-t-il un effet secondaire connu, pratique et erroné de la liaison /dev/random
à /dev/urandom
des systèmes Linux comme cela est fait par défaut sur les systèmes FreeBSD? Ou pourrait-on envisager de définir cela de façon permanente (dans un script à la fin du processus de démarrage par exemple) en cas de problèmes répétitifs dus au /dev/random
verrouillage d'un service?
Sous Linux,
/dev/random
donne des bits aléatoires de haute qualité. Ils sont issus de sources non prévisibles et non reproductibles, externes à la machine. En revanche,/dev/urandom
utilise les mêmes données aléatoires que/dev/random
(si disponibles), s'il n'y en a pas, il utilise un générateur de nombres pseudo-aléatoires, qui est déterministe . Dans la plupart des cas, il est assez imprévisible, mais pas pour les applications très exigeantes comme la cryptographie, et encore moins pour la création de clés à longue durée de vie comme pour GPG.la source
/dev/urandom
est bien pour la cryptographie ./dev/urandom
, vous n'avez aucune raison de faire confiance à GPG.urandom
vsrandom
, confirmez-vous que le remplacement du/dev/random
fichier par un lien ne devrait avoir aucun autre effet secondaire et être une alternative viable à l'rngd
astuce que j'ai mentionnée?