Est-ce mal de lier / dev / random à / dev / urandom sous Linux?

Je teste actuellement gpg --genkeysur une machine virtuelle Linux. Malheureusement, ce logiciel semble s'appuyer sur /dev/randompour 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/urandomplace, 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 rngddémon et le configurent pour l'utiliser /dev/urandomcomme 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/randomet en le liant à la /dev/urandomplace:

rm /dev/random
ln -s /dev/urandom /dev/random

Je vois cela comme un paramètre indiquant "Je fais confiance en /dev/urandomtant 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/urandomdes 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/randomverrouillage d'un service?

Voir Mythes sur urandom , il n'y a pas d'attaque connue sur / dev / urandom qui ne serait pas également une attaque sur / dev / random. Le principal problème d'un système Linux est qu'il a cloné et exécuté en tant que plusieurs machines virtuelles sans réinitialiser le pool d'entropie enregistré après le clonage. C'est un cas d'angle tangent à ce que vous voulez.

Une chose différente /dev/randomest qu'elle arrête la sortie après l'utilisation du pool d'entropie. essaye ça:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomcependant, réutilisera le même pool pour continuer la sortie. comme indiqué ici:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Lorsque vous essayez de capturer ces appareils spéciaux, votre invite peut être foirée. Il suffit de taper resetet d'entrer, votre terminal sera de retour à la normale)

À utiliser /dev/urandomlorsque vous avez juste besoin de remplir quelque chose avec un flux constant de bits "aléatoires". Utilisez /dev/randompour les clés dont vous avez besoin d'être absolument aléatoire.

Sous Linux, /dev/randomdonne des bits aléatoires de haute qualité. Ils sont issus de sources non prévisibles et non reproductibles, externes à la machine. En revanche, /dev/urandomutilise 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.