toujours utiliser / dev / urandom.

/ dev /urandom et/dev / random utilisent le même générateur de nombres aléatoires. Ils sont tous les deux ensemencés par le même bassin d'entropie. Tous deux donneront un nombre tout aussi aléatoire d'une taille arbitraire. Ils peuvent tous les deux donner une quantité infinie de nombres aléatoires avec seulement une graine de 256 bits. Tant que la graine initiale a 256 bits d'entropie, vous pouvez avoir un approvisionnement infini de nombres aléatoires arbitrairement longs. Vous ne gagnez rien en utilisant /dev/random. Le le fait qu'il y ait deux périphériques est un défaut dans L'API Linux.

si vous êtes préoccupé par l'entropie, utiliser /dev/random ne va pas corriger cela. Mais il ralentira votre application tout en ne générant pas de nombres plus aléatoires que /dev/urandom. Et si vous n'êtes pas concerné par entropy, pourquoi utilisez-vous /dev/random du tout?

Voici une bien meilleure/explication approfondie sur pourquoi vous devriez toujours utiliser / dev / urandom: http://www.2uo.de/myths-about-urandom /

Quelles sont les différences entre /dev/random et /dev/urandom ?

/dev/random et /dev/urandom sont des interfaces avec le générateur de nombres aléatoires du noyau:

• Lecture renvoie un flux d'octets aléatoires assez solide pour une utilisation en cryptographie
• leur écrire fournira les données du noyau pour mettre à jour le pool entropy

quand il vient aux différences, il dépend du système d'exploitation:

• sur Linux, lecture de /dev/random peut bloquer, ce qui limite considérablement son utilisation dans la pratique
• sous FreeBSD, il n'y en a pas. /dev/urandom n'est qu'un lien symbolique vers /dev/random .

Quand dois-je les utiliser? Quand ne devrais-je pas les utiliser?

Il est très difficile de trouver un cas d'utilisation où vous devez utiliser /dev/random plus /dev/urandom .

Danger de blocage:

• il s'agit d'un véritable problème auquel vous devrez faire face lorsque vous décidez d'utiliser /dev/random . Pour les utilisations simples comme ssh-keygen il devrait être correct d'attendre quelques secondes, mais pour la plupart des autres situations, il ne sera pas une option.
• Si vous utilisez /dev/random , vous devez l'ouvrir en non bloquant mode et de fournir une sorte de notification de l'utilisateur si l'entropie n'est pas immédiatement disponible.

la Sécurité:

• sous FreeBSD, il n'y a aucune différence de toute façon, mais aussi sous Linux /dev/urandom est considéré comme sûr pour presque tous les cas pratiques (E. g, un rand de / dev / urandom est-il sécurisé pour une clé de connexion? et mythes about /dev/urandom ).
• les situations où cela pourrait faire une différence sont des cas extrêmes comme une nouvelle installation Linux. Pour citer la page du manuel de Linux:

l'interface /dev/random est considérée comme une interface legacy, et /dev/urandom est préféré et suffisant tous les cas d'utilisation, à l'exception des applications qui nécessitent un caractère aléatoire au début du démarrage; pour ces applications, getrandom (2) doivent être utilisées au lieu de cela, parce qu'il bloquera jusqu'à ce que le pool d'entropie soit initialisé.

si un fichier seed est sauvegardé à travers les redémarres comme recommandé ci-dessous (toutes les distributions Linux majeures ont fait ceci depuis 2000 au moins), la sortie est cryptographiquement sécurisé contre les attaquants sans accès local root comme dès qu'il est rechargé dans la séquence d'amorçage, et parfaitement adapté pour les clés de session de cryptage réseau. Depuis lit de /dev/random peut bloquer, les utilisateurs seront généralement voulez l'ouvrir en mode non bloquant (ou effectuer une lecture avec temporisation), et de fournir une sorte de notification de l'utilisateur si l'entropie n'est pas immédiatement disponible.

recommandation

en règle générale, /dev/urandom doit être utilisé pour tout sauf les clés GPG/SSL/SSH de longue durée.

réponse Courte

Utiliser /dev/urandom

Longue Réponse

ils sont tous les deux alimentés par le même générateur de nombres pseudorandom cryptographiquement sécurisé (CSPRNG). Le fait que /dev/random attend l'entropie (ou plus précisément, attend l'estimation de l'entropie par le système pour atteindre un niveau approprié) ne fait une différence que lorsque vous utilisez un algorithme théoriquement sûr de l'information, par opposition à un calcul sécurisé algorithme. Le premier englobe des algorithmes que vous n'utilisez probablement pas, comme le partage Secret de Shamir et le bloc-notes unique. Ce dernier contient des algorithmes que vous utilisez et dont vous vous souciez réellement, tels que AES, RSA, Diffie-Hellman, OpenSSL, GnuTLS, etc.

donc il n'a pas d'importance si vous utilisez des nombres de /dev/random puisqu'ils sont pompés hors D'un CSPRNG de toute façon, et il est "théoriquement possible" de briser les algorithmes que vous êtes probablement en les utilisant avec de toute façon.

enfin, ce bit" théoriquement possible " signifie exactement cela. Dans ce cas, cela signifie utiliser toute la puissance de calcul dans le monde, pour la quantité de temps que l'univers a existé pour fissurer l'application.

par conséquent, il est pratiquement inutile d'utiliser /dev/random

Donc de l'utiliser /dev/urandom

Sources

1 2 3