Quand utiliser /dev/random contre /dev/urandom ?

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

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

Réponse acceptée :

TL;DR

Utilisez /dev/urandom à des fins pratiques.

La réponse la plus longue dépend du type d'Unix que vous utilisez.

Linux

Historiquement, /dev/random et /dev/urandom ont été introduits en même temps.

Comme @DavidSchwartz l'a souligné dans un commentaire, en utilisant /dev/urandom est préféré dans la grande majorité des cas. Lui et d'autres ont également fourni un lien vers les excellents mythes sur /dev/urandom article que je recommande pour une lecture plus approfondie.

En résumé :

La page de manuel est trompeuse.
Les deux sont alimentés par le même CSPRNG pour générer de l'aléatoire (schémas 2 et 3)
/dev/random se bloque lorsqu'il manque d'entropie,
donc la lecture de /dev/random peut arrêter l'exécution du processus.
La quantité d'entropie est estimée de manière prudente, mais n'est pas comptabilisée
/dev/urandom ne bloquera jamais.
Dans de rares cas très peu de temps après le démarrage, le CSPRNG peut ne pas avoir eu suffisamment d'entropie pour être correctement amorcé et /dev/urandom peut ne pas produire un caractère aléatoire de haute qualité.
L'entropie faible n'est pas un problème si le CSPRNG a été initialisé correctement.
Le CSPRNG est constamment renouvelé.
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 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 tampon à usage unique avec une sécurité théorique de l'information

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 à partir de /dev/random sera bloquée, mais méfiez-vous des éventuelles conditions de concurrence.

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

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

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

macOS

Peu importe, comme le dit Wikipédia :

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. L'iOS d'Apple utilise également Yarrow.

FreeBSD

Peu importe, comme le dit Wikipédia :

/dev/urandom est juste un lien vers /dev/random et ne bloque que jusqu'à ce qu'il soit correctement ensemencé.

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

Connexe :Linux – Comment faire fonctionner Oracle Java 7 avec setcap cap_net_bind_service+ep ?

NetBSD

Utilisez /dev/urandom , en supposant que votre système a lu au moins une fois depuis /dev/random pour assurer un bon amorçage initial.

La page de manuel rnd(4) indique :

/dev/urandom ne bloque jamais.

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

Les applications doivent lire depuis /dev/urandom lorsqu'ils ont besoin de
données générées aléatoirement, par ex. clés cryptographiques ou graines 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 des services qui communiquent avec
Internet ou qui nécessitent une cryptographie, afin d'éviter
de générer des clés de manière prévisible.