Quand utiliser / dev / random vs / dev / urandom

Devrais-je utiliser /dev/randomou /dev/urandom?

Dans quelles situations est-ce que je préférerais l'un plutôt que l'autre?

TL; DR

Utilisez /dev/urandomà des fins plus pratiques.

La réponse la plus longue dépend de la version d’Unix que vous utilisez.

Linux

Historiquement, /dev/randomet /dev/urandomont tous deux été introduits en même temps.

Comme @DavidSchwartz l'a souligné dans un commentaire , l'utilisation /dev/urandomest préférable dans la grande majorité des cas. Lui et d'autres ont également fourni un lien vers l'excellent article Myths about/dev/urandom que je recommande aux lecteurs de lire davantage.

En résumé:

• La page de manuel est trompeuse
• Les deux sont alimentés par le même CSPRNG pour générer le caractère aléatoire ( diagrammes 2 et 3 )
• /dev/random bloque quand il manque d'entropie
• La quantité d'entropie est estimée de manière conservatrice, mais n'est pas comptée
• /dev/urandomne bloquera jamais, la lecture de /dev/randompeut arrêter l'exécution des processus.
• Dans de rares cas, très peu de temps après le démarrage, le CSPRNG peut ne pas avoir assez d'entropie pour être correctement ensemencé et /dev/urandompeut ne pas produire un caractère aléatoire de haute qualité.
• L'entropie trop faible n'est pas un problème si le CSPRNG a été initialement correctement ensemencé
• Le CSPRNG est constamment réensemencé
• Sous Linux 4.8 et versions ultérieures, /dev/urandomle pool d'entropie (utilisé par /dev/random) n'est pas épuisé, mais la sortie CSPRNG est utilisée en amont.
• Utilisez /dev/urandom.

Exceptions à la règle

Dans la pile de Cryptography échange Quand utiliser /dev/randomplus /dev/urandomsous Linux @otus donne deux cas d'utilisation :

1. Peu de temps après l’amorçage sur un périphérique à entropie faible, si suffisamment d’entropie n’a pas encore été générée pour permettre un amorçage correct /dev/urandom.

2. Générer un pavé unique avec sécurité informatique

Si vous êtes inquiet pour (1), vous pouvez vérifier l’entropie disponible dans/dev/random .

Si vous faites (2) vous le saurez déjà :)

Remarque: vous pouvez vérifier si la lecture de / dev / random bloquera , mais méfiez-vous des conditions de concurrence possibles.

Alternative: n'utilisez ni l'un ni l'autre!

@otus a également souligné que le getrandom()système lirait /dev/urandomet ne bloquerait que si l'entropie initiale de la graine n'était pas disponible.

Il est difficile de changer /dev/urandomd’utilisationgetrandom() , mais il est concevable de créer un nouveau /dev/xrandompériphérique en fonction de celui-ci getrandom().

macOS

Cela n'a pas d'importance, comme le dit Wikipedia :

macOS utilise Yarrow 160 bits basé sur SHA1. Il n'y a pas de différence entre / dev / random et / dev / urandom; les deux se comportent de manière identique. Apple iOS utilise également Yarrow.

FreeBSD

Cela n'a pas d'importance, comme le dit Wikipedia :

/dev/urandomn’est qu’un lien vers /dev/randomet ne bloque que jusqu’à ce qu’il soit correctement ensemencé.

Cela signifie qu’après le démarrage, FreeBSD est suffisamment intelligent pour attendre jusqu’à ce que suffisamment d’entropie ait été collectée avant de fournir un flux sans fin de qualité aléatoire.

NetBSD

Utilisez-le /dev/urandom, en supposant que votre système l’a lu au moins une fois /dev/randompour garantir un ensemencement initial correct.

La page de manuel rnd (4) indique :

/dev/urandom Ne bloque jamais.

/dev/randomParfois des blocs. Bloquera tôt au démarrage si l'état du système est prévisible.

Les applications doivent lire dans / dev / urandom quand elles ont besoin de données générées aléatoirement, telles que des clés cryptographiques ou des bases de données de simulation.

Les systèmes doivent être conçus pour lire judicieusement au moins une fois dans / dev / random au démarrage avant de lancer des services qui parlent à Internet ou qui nécessitent une cryptographie, pour éviter de générer des clés de manière prévisible.

Traditionnellement, la seule différence entre /dev/urandomet /dev/randomest ce qui se produit lorsque le noyau pense qu’il n’ya pas d’entropie dans le système - /dev/randoméchec fermé, /dev/urandoméchec ouvert. Les deux pilotes ont été l' entropie de approvisionnent add_disk_randomness(), add_interrupt_randomness()et add_input_randomness(). Voir /drivers/char/random.cpour plus de détails.

Édité pour ajouter: À partir de Linux 4.8 a /dev/urandomété retravaillé pour utiliser CSPRNG.

Alors, quand devriez-vous échouer fermé? Pour tout type d'utilisation cryptographique, en particulier l'ensemencement de DRBG. Il existe un très bon article expliquant les conséquences de l’utilisation /dev/urandomlors de la génération de clés RSA et du manque d’entropie. Lisez Mining Your Ps and Qs .

C'est en quelque sorte une réponse "moi aussi", mais cela renforce la recommandation de Tom Hale. Cela s'applique carrément à Linux.

• Utilisation /dev/urandom
• Ne pas utiliser /dev/random

Selon Theodore Ts'o, sur la liste de diffusion Linux Kernel Crypto, /dev/randomest déconseillé depuis une décennie. De Re: [RFC PATCH v12 3/4] Générateur de nombres aléatoires Linux :

Pratiquement personne n'utilise / dev / random. C'est essentiellement une interface obsolète; Les principales interfaces recommandées depuis plus de dix ans sont / dev / urandom et maintenant getrandom (2).

Nous testons régulièrement /dev/randomet il subit des échecs fréquents. Le test effectue les trois étapes suivantes: (1) drainer /dev/randomen demandant 10K octets en mode non bloquant; (2) demander 16 octets en mode bloquant (3) essayer de compresser le bloc pour voir s'il est aléatoire (test de l'homme pauvre). Le test prend quelques minutes à compléter.

Le problème est si grave sur les systèmes Debain (i686, x86_64, ARM et MIPS) que nous avons demandé à GCC Compile Farm d’installer le rng-toolspaquet pour leurs machines de test. À partir de rng-tools sur gcc67 et gcc68 :

Je voudrais demander que les outils rng soient installés sur gcc67 et gcc68. Ce sont des systèmes Debian et / dev / random souffre d’épuisement d’entropie sans outils rng lors de tests de torture des bibliothèques qui utilisent le périphérique.

Les BSD et OS X semblent OK. Le problème est définitivement Linux.

Il convient également de mentionner que Linux ne consigne pas les erreurs du générateur de journaux. Ils ne voulaient pas que les entrées remplissent le journal système. À ce jour, la plupart des échecs sont silencieux et ne sont pas détectés par la plupart des utilisateurs.

La situation devrait bientôt changer car le noyau va imprimer au moins un message d'échec. De [PATCH] random: élimine les avertissements du compilateur et corrige la course sur la liste de diffusion cryptée du noyau:

Plus précisément, j'ai ajouté depends on DEBUG_KERNEL. Cela signifie que ces avertissements utiles ne toucheront que les autres développeurs du noyau. C'est probablement exactement ce que nous voulons. Si les différents développeurs associés voient un avertissement provenant de leur sous-système particulier, ils seront plus motivés pour le résoudre. Les utilisateurs ordinaires sur les noyaux de distribution ne devraient pas voir les avertissements ni le spam, car généralement les utilisateurs n'utilisent pas DEBUG_KERNEL.

Je pense que c'est une mauvaise idée de supprimer tous les messages du point de vue de l'ingénierie de la sécurité.

Beaucoup de gens ne courent pas les noyaux de débogage. La plupart des utilisateurs qui souhaitent ou ont besoin de connaître les problèmes ne réalisent pas que cela se produit. Considérez que la raison pour laquelle nous avons appris les problèmes de systemd était due à dmesg.

La suppression de tous les messages pour toutes les configurations génère un réseau plus large que nécessaire. Les configurations susceptibles d'être détectées et corrigées passeront probablement inaperçues. Si le problème n'est pas mis au jour, il ne sera pas corrigé.

J'ai l'impression que le noyau prend des décisions stratégiques pour certaines organisations. Pour ceux dont le matériel est effectivement non corrigible, l’organisation doit décider quoi faire en fonction de son adversité en matière de risque. Ils peuvent décider de supporter le risque ou d’actualiser le matériel. Cependant, sans informations sur la question, ils peuvent même ne pas se rendre compte qu'ils ont un élément pouvant faire l'objet d'une action

Le compromis finalement atteint plus tard dans le thread était au moins un dmesg par module appelant.