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

13

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?

WhiteWinterWolf
la source

Réponses:

2

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.

Walter
la source
0

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.

Daniel
la source
3
La question de l'OP était: y a-t-il un effet secondaire connu, pratique et erroné de lier / dev / random à / dev / urandom sur les systèmes Linux comme cela est fait par défaut sur les systèmes FreeBSD?
contre-mode
Intéressant, si la différence est aussi prononcée, ils ne devraient pas être liés. La plupart des autres discussions parviennent finalement à un consensus sur aucune différence après le démarrage, mais ce comportement peut indiquer une différence plus durable.
KalleMP
-2

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.

vonbrand
la source
6
C'est faux. /dev/urandomest bien pour la cryptographie .
Gilles 'SO- arrête d'être méchant'
@Gilles qui dépend de votre degré de paranoïa. Pour GPG, tout le monde est affecté par votre clé (indirectement).
vonbrand
5
Si vous ne faites pas confiance /dev/urandom, vous n'avez aucune raison de faire confiance à GPG.
Gilles 'SO- arrête d'être méchant'
3
@vonbrand: Selon mon degré de paranoïa, si je dois choisir entre un PRNG vérifié mathématiquement pour générer de l'aléatoire ou un utilisateur obligé de taper un plein écran de déchets "asdfghasdfghasdfgh", je choisirais de loin le logiciel PRNG. Je comprends votre point de vue qu'un ordinateur n'est pas bon pour générer de l'aléatoire, mais les humains sont encore pires. Néanmoins, pour revenir à ma question, à l'exception du débat urandomvs random, confirmez-vous que le remplacement du /dev/randomfichier par un lien ne devrait avoir aucun autre effet secondaire et être une alternative viable à l' rngdastuce que j'ai mentionnée?
WhiteWinterWolf
2
C'est faux. Ils utilisent le MÊME RNG, mais des blocs aléatoires s'il devine qu'il n'y a pas assez d'entropie.
Duncan X Simpson