Cette question est assez ancienne. Mais toujours d'actualité donc je vais donner ma réponse. Aujourd'hui, de nombreux processeurs sont équipés d'un générateur de nombres aléatoires (RNG) matériel intégré. De plus, de nombreux systèmes sont livrés avec un module de plate-forme de confiance (TPM) qui fournit également un RNG. Il existe également d'autres options qui peuvent être achetées, mais il est probable que votre ordinateur dispose déjà de quelque chose.
Vous pouvez utiliser rngd du package rng-utils sur la plupart des distributions Linux pour générer davantage de données aléatoires. Par exemple sur fedora 18 tout ce que j'avais à faire pour activer l'ensemencement depuis le TPM et le CPU RNG (instruction RDRAND) était :
# systemctl enable rngd
# systemctl start rngd
Vous pouvez comparer la vitesse avec et sans rngd. C'est une bonne idée d'exécuter rngd -v -f depuis la ligne de commande. Cela vous montrera les sources d'entropie détectées. Assurez-vous que tous les modules nécessaires à la prise en charge de vos sources sont chargés. Pour utiliser TPM, il doit être activé via les outils tpm. mettre à jour :voici un tutoriel sympa.
BTW, j'ai lu sur Internet des inquiétudes concernant le fait que TPM RNG soit souvent cassé de différentes manières, mais je n'ai rien lu de concret contre les RNG trouvés dans les puces Intel, AMD et VIA. Il serait préférable d'utiliser plusieurs sources si vous vous souciez vraiment de la qualité aléatoire.
urandom convient à la plupart des cas d'utilisation (sauf parfois lors du démarrage précoce). De nos jours, la plupart des programmes utilisent urandom au lieu de random. Même openssl le fait. Voir les mythes sur urandom et la comparaison d'interfaces aléatoires.
Récemment, Fedora et RHEL/CentOS rng-tools prennent également en charge l'entropie de gigue. Vous pouvez le faire par manque d'options matérielles ou si vous lui faites simplement plus confiance qu'à votre matériel.
MISE À JOUR : une autre option pour plus d'entropie est HAVEGED (qualité remise en question). Sur les machines virtuelles il y a un kvm/qemu VirtIORNG (recommandé).
MISE À JOUR 2 : Dans Linux 5.6, le noyau fait sa propre entropie de gigue.
Sur la plupart des systèmes Linux, /dev/random est alimenté par l'entropie réelle recueillie par l'environnement. Si votre système ne fournit pas une grande quantité de données de /dev/random , cela signifie probablement que vous ne générez pas suffisamment de caractère aléatoire environnemental pour l'alimenter.
Je ne sais pas pourquoi vous pensez /dev/urandom est "plus lent" ou de meilleure qualité. Il réutilise un pool d'entropie interne pour générer un pseudo-aléatoire - ce qui en fait une qualité légèrement inférieure - mais il ne bloque pas. Généralement, les applications qui ne nécessitent pas de chiffrement de haut niveau ou à long terme peuvent utiliser /dev/urandom de manière fiable.
Essayez d'attendre un peu puis de lire à partir de /dev/urandom encore. Il est possible que vous ayez épuisé le pool d'entropie interne en lisant autant de /dev/random , brisant les deux générateurs - permettant à votre système de créer plus d'entropie devrait les reconstituer.
Voir Wikipedia pour plus d'informations sur /dev/random et /dev/urandom .