Est-ce que j'ai compris /dev/urandom ?

Question

J'ai lu des articles sur /dev/urandom, et d'après ce que j'ai compris, /dev/random crée des nombres cryptographiquement aléatoires en tirant parti de plusieurs événements tels que la synchronisation des paquets réseau, etc. Cependant, ai-je bien compris que /dev/urandom utilise un PRNG, ensemencé avec un nombre provenant de /dev/random ? Ou est-ce qu'il utilise simplement /dev/random tant qu'il y a des bits -- et quand il n'y en a plus, il se rabat sur un PRNG avec une graine récupérée d'où ?

Answer 1

De la page de manuel d'urandom :

Le générateur de nombres aléatoires recueille bruit environnemental provenant des pilotes et d'autres sources dans un d'entropie. Le générateur conserve également conserve également une estimation du nombre de bits de bruit dans la réserve d'entropie. À partir de cette réserve d'entropie, des nombres aléatoires sont créés.

En lecture, le périphérique /dev/random ne retournera que des octets aléatoires dans le nombre estimé de bits de bruit dans le pool d'entropie. /dev/random devrait convenir aux utilisations qui nécessitent d'un caractère aléatoire de très haute qualité comme comme le one-time pad ou la génération de clés. Lorsque le pool d'entropie est vide, les lectures depuis /dev/random vont bloqueront jusqu'à ce qu'un bruit environnemental supplémentaire jusqu'à ce que des bruits environnementaux supplémentaires soient recueillis.

Une lecture à partir du périphérique /dev/urandom ne bloquera pas en attendant plus d entropie . Par conséquent, s'il n'y a pas assez d'entropie dans le pool d'entropie d'entropie, les valeurs retournées sont théoriquement vulnérables à une attaque cryptographique sur les algorithmes utilisés par le pilote. La connaissance de la manière comment le faire n'est pas disponible dans la littérature non classifiée actuelle, mais il est théoriquement possible qu'une telle une telle attaque puisse exister. Si cela est une préoccupation dans votre application, utilisez /dev/random à la place.

Les deux utilisent un PRNG, bien que l'utilisation de données environnementales et d'un pool d'entropie rende le crackage du PRNG astronomiquement plus difficile, et impossible sans collecter exactement les mêmes données environnementales.

En règle générale, sans matériel spécialisé et coûteux qui recueille des données à partir, par exemple, d'événements quantiques, il n'existe pas de véritable générateur de nombres aléatoires (c'est-à-dire un RNG qui génère des nombres vraiment imprévisibles) ; cependant, à des fins cryptographiques, /dev/random ou /dev/urandom suffiront (la méthode utilisée est celle d'un CPRNG, générateur de nombres pseudo-aléatoires cryptographiques).

Le pool d'entropie et la lecture bloquante de /dev/random sont utilisés comme garde-fou pour garantir l'impossibilité de prédire le nombre aléatoire ; si, par exemple, un attaquant a épuisé le pool d'entropie d'un système, il est probable, bien que très improbable avec la technologie actuelle, qu'il puisse prédire la sortie de /dev/urandom qui n'a pas été réalimenté depuis longtemps (bien que cela nécessiterait également que l'attaquant épuise la capacité du système à collecter plus d'entropies, ce qui est également astronomiquement improbable).

Answer 2

En fait, ce dont vous avez besoin dans la pratique, c'est ce que le logiciel FreeBSD /dev/urandom fournit : il lira une graine initiale d'une longueur suffisante de /dev/random puis utiliser un PRNG. Ainsi, il peut bloquer initialement (juste après le démarrage du système) mais une fois qu'il a rassemblé suffisamment d'entropie, il ne bloque jamais. Cela fournit le niveau d'aléatoire nécessaire à la plupart des protocoles cryptographiques, sans pour autant bloquer indûment.

Linux /dev/urandom est similaire, sauf qu'il ne bloquera jamais, et risque donc de renvoyer un caractère aléatoire de mauvaise qualité s'il est utilisé juste après le démarrage. D'un autre côté, /dev/random peut se bloquer même longtemps après le démarrage, ce qui est également un problème. J'ai souvent vu des serveurs se bloquer mystérieusement, parce qu'un logiciel insistait sur l'utilisation de /dev/random et le serveur sans clavier ne recevait pas assez d'entropie.

La distribution Linux habituelle enregistre à l'arrêt une graine aléatoire obtenue à partir de /dev/urandom et l'injecter à nouveau au prochain démarrage, garantissant ainsi la qualité de l'aléatoire fournie par /dev/urandom . Ce n'est qu'au cours de l'installation du système d'exploitation que la qualité cryptographique devient un problème, et ce n'est généralement pas le cas, car l'installation implique un certain nombre d'interactions avec l'être humain qui l'effectue, ce qui produit des hordes d'entropie.

Pour résumer, sous Linux et FreeBSD, vous devriez utiliser /dev/urandom pas /dev/random .

Answer 3

Citation : aquí

/dev/random se bloquera après que la réserve d'entropie soit épuisée. Il restera bloqué jusqu'à ce que des données supplémentaires aient été collectées à partir des sources d'entropie disponibles. Cela peut ralentir la génération de données aléatoires.

/dev/urandom ne sera pas bloqué. Au lieu de cela, il réutilisera le pool interne pour produire plus de bits pseudo-aléatoires.

---

/dev/urandom est le mieux utilisé lorsque :

• Vous voulez juste un grand fichier avec des données aléatoires pour une sorte de test.
• Vous utilisez le dd commande permettant d'effacer les données d'un disque en les remplaçant par des données aléatoires.
• Presque partout ailleurs où vous n'avez pas une bonne raison d'utiliser /dev/random à la place.

/dev/random est susceptible d'être le meilleur choix lorsque :

• Le caractère aléatoire est essentiel à la sécurité de la cryptographie dans votre application - tampons à usage unique, génération de clés.