Il y a bien une différence : /dev/random/ garantit de renvoyer des bits réellement aléatoires (et non pseudo-aléatoires), tandis que /dev/urandom peut retomber sur un comportement prédictible s'il est utilisé avant que le pool d'entropie soit suffisamment plein. Cela pose problème pour les programmes lancés pendant le démarrage d'un système, qui font alors face à un dilemme :
soit lire depuis /dev/urandom, qui est non-bloquant mais risque dans certains cas de fournir une entropie insuffisante (et donc rendre ces programmes potentiellement vulnérables, s'ils utilisent ces bits aléatoires pour des fonctions de sécurité)
soit lire depuis /dev/random et risquer de bloquer pendant de longues secondes, le temps que le pool d'entropie soit initialisé
C'est très bien expliqué dans le document de proposition du nouveau RNG, avec des mesures concrètes assez édifiantes : le pool d'entropie actuel peut ainsi prendre 30 secondes pour collecter suffisamment d'entropie (notamment sur une VM, qui dispose de sources d'entropie limitées), ce qui est beaucoup trop long pour les besoins des programmes lancés au démarrage. Avec la proposition de nouveau RNG, ce délai descend à une seconde ou moins, ce qui est beaucoup plus supportable.
Pour un exemple concret, Python utilise désormais la version bloquante de l'appel système getrandom(), ce qui offre des garanties plus fortes que de lire depuis /dev/urandom: https://www.python.org/dev/peps/pep-0524/
[^] # Re: À propos de /dev/urandom
Posté par Antoine . En réponse à la dépêche Sortie du noyau Linux 4.9. Évalué à 10.
Il y a bien une différence :
/dev/random/garantit de renvoyer des bits réellement aléatoires (et non pseudo-aléatoires), tandis que/dev/urandompeut retomber sur un comportement prédictible s'il est utilisé avant que le pool d'entropie soit suffisamment plein. Cela pose problème pour les programmes lancés pendant le démarrage d'un système, qui font alors face à un dilemme :soit lire depuis
/dev/urandom, qui est non-bloquant mais risque dans certains cas de fournir une entropie insuffisante (et donc rendre ces programmes potentiellement vulnérables, s'ils utilisent ces bits aléatoires pour des fonctions de sécurité)soit lire depuis
/dev/randomet risquer de bloquer pendant de longues secondes, le temps que le pool d'entropie soit initialiséC'est très bien expliqué dans le document de proposition du nouveau RNG, avec des mesures concrètes assez édifiantes : le pool d'entropie actuel peut ainsi prendre 30 secondes pour collecter suffisamment d'entropie (notamment sur une VM, qui dispose de sources d'entropie limitées), ce qui est beaucoup trop long pour les besoins des programmes lancés au démarrage. Avec la proposition de nouveau RNG, ce délai descend à une seconde ou moins, ce qui est beaucoup plus supportable.
Pour un exemple concret, Python utilise désormais la version bloquante de l'appel système
getrandom(), ce qui offre des garanties plus fortes que de lire depuis/dev/urandom:https://www.python.org/dev/peps/pep-0524/