Quand utiliser / dev / random vs / dev / urandom

Question

Dois-je utiliser /dev/random ou /dev/urandom?

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

Tom Hale · Accepted Answer

TL; DR

Utilisez /dev/urandom Pour la plupart des applications pratiques.

La réponse la plus longue dépend de la saveur d'Unix que vous utilisez.

Linux

Historiquement, /dev/random Et /dev/urandom Ont tous deux été introduits en même temps.

Comme l'a souligné @DavidSchwartz dans un commentaire , l'utilisation de /dev/urandom Est préférable dans la grande majorité des cas. Lui et d'autres ont également fourni un lien vers l'excellent article Mythes sur /dev/urandom que je recommande pour une lecture plus approfondie.

En résumé:

page de manuel est trompeur
Les deux sont alimentés par le même CSPRNG pour générer de l'aléatoire ( diagrammes 2 et )
/dev/random Se bloque lorsqu'il manque d'entropie
La quantité d'entropie est estimée de façon prudente, mais non comptée
/dev/urandom Ne bloquera jamais, la lecture de /dev/random Peut interrompre 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 suffisamment d'entropie pour être correctement semé et /dev/urandom Peut ne pas produire de haute qualité aléatoire.
L'entropie faible n'est pas un problème si le CSPRNG a été correctement initialisé correctement
Le CSPRNG est constamment réensemencé
Sous Linux 4.8 et versions ultérieures, /dev/urandom N'épuise pas le pool d'entropie (utilisé par /dev/random) Mais utilise la sortie CSPRNG en amont.
Utilisez /dev/urandom.

Exceptions à la règle

Dans le Cryptography Stack Exchange Quand utiliser /dev/random Sur /dev/urandom Sous Linux @otus donne deux cas d'utilisation :

Peu de temps après le démarrage sur un périphérique à faible entropie, si suffisamment d'entropie n'a pas encore été générée pour amorcer correctement /dev/urandom.
Génération d'un bloc ponctuel avec sécurité théorique de l'information

Si vous vous inquiétez de (1), vous pouvez vérifiez l'entropie disponible dans /dev/random .

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

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

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

@otus a également souligné que le système getrandom() lira dans /dev/urandom et ne bloquera que si l'entropie initiale de la graine n'est pas disponible.

Il y a problèmes avec la modification de /dev/urandom Pour utiliser getrandom() , mais il est concevable qu'un nouveau périphérique /dev/xrandom Soit créé sur la base de getrandom().

macOS

Cela n'a pas d'importance, car Wikipedia dit :

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

FreeBSD

Cela n'a pas d'importance, car Wikipedia dit :

/dev/urandom N'est qu'un lien vers /dev/random Et ne bloque que jusqu'à ce qu'il soit correctement semé.

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

NetBSD

Utilisez /dev/urandom, En supposant que votre système a lu au moins une fois dans /dev/random Pour garantir un amorçage initial correct.

La page de manuel rnd (4) indique :

/dev/urandom Ne bloque jamais.

/dev/random Parfois bloque. Se bloquera tôt au démarrage si l'état du système est connu pour être prévisible.

Les applications doivent lire à partir de/dev/urandom lorsqu'elles ont besoin de données générées de manière aléatoire, par exemple clés ou graines cryptographiques pour les simulations.

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

user56041 · Answer

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

Utilisation /dev/urandom
N'utilisez pas /dev/random

Selon Theodore Ts'o sur la liste de diffusion Linux Kernel Crypto, /dev/random est obsolète 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 d'une décennie sont/dev/urandom, et maintenant, getrandom (2).

Nous testons régulièrement /dev/random et il subit des échecs fréquents. Le test effectue les trois étapes: (1) vidange /dev/random en demandant 10 000 octets en mode non bloquant; (2) demande 16 octets en mode blocage (3) tente de compresser le bloc pour voir s'il est aléatoire (test du pauvre). Le test prend quelques minutes.

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-tools package pour leurs machines de test. De Installer rng-tools sur gcc67 et gcc68 :

Je voudrais demander que rng-tools soit installé sur gcc67 et gcc68. Ce sont des systèmes Debian, et/dev/random souffre d'épuisement de l'entropie sans rng-tools lors de tests de torture sur les 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 n'enregistre pas les défaillances du générateur. 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 changer sous peu car le noyau va imprimer au moins un message d'échec. De [PATCH] random: silence les avertissements du compilateur et correction de la course sur la liste de diffusion crypto du noyau:

Plus précisément, j'ai ajouté depends on DEBUG_KERNEL. Cela signifie que ces avertissements utiles ne feront que pousser 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 à le corriger. Les utilisateurs ordinaires sur les noyaux de distribution ne devraient pas voir du tout les avertissements ou 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 sécurité.

Beaucoup de gens n'exécutent pas de noyaux de débogage. La plupart des utilisateurs qui veulent ou doivent connaître les problèmes ne se rendront pas compte que cela se produit. Considérez, la raison pour laquelle nous avons appris des problèmes de systemd était due à dmesg.

La suppression de tous les messages pour toutes les configurations crée un réseau plus large que nécessaire. Les configurations qui pourraient potentiellement être détectées et corrigées passeront probablement inaperçues. Si le problème n'est pas mis en évidence, il ne sera pas résolu.

J'ai l'impression que le noyau prend des décisions politiques pour certaines organisations. Pour ceux qui ont un matériel qui ne peut pas être réparé, l'organisation doit alors décider quoi faire en fonction de l'adversité du risque. Ils peuvent décider de vivre avec le risque, ou ils peuvent décider de rafraîchir le matériel. Cependant, sans informations sur le problème, ils peuvent même ne pas se rendre compte qu'ils ont un élément donnant lieu à une action.

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

Kirill Sinitski · Answer

Traditionnellement, la seule différence entre /dev/urandom Et /dev/random Est ce qui se passe lorsque le noyau pense qu'il n'y a pas d'entropie dans le système - /dev/random Ne se ferme pas, /dev/urandom Ne s'ouvre pas . Les deux pilotes achetaient l'entropie à partir de add_disk_randomness(), add_interrupt_randomness() et add_input_randomness(). Voir /drivers/char/random.c Pour les détails.

Modifié pour ajouter: à partir de Linux 4.8 /dev/urandom A é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 document expliquant les conséquences de l'utilisation de /dev/urandom Lors de la génération de clés RSA et de l'absence d'entropie suffisante. Lisez Exploration de vos Ps et Qs .