L’article que j’ai cité explique bien comment fonctionne /dev/random et /dev/urandom (ils utilisent le même PRNG).
La différence n'est pas là. La différence est dans le fait que /dev/random est bloquant jusqu'à ce qu'il y ait assez d'entropie (garantissant ainsi que les bits renvoyés ne peuvent être prédits), alors que /dev/urandom peut renvoyer des bits uniquement pseudo-aléatoires (donc théoriquement prédictibles) s'il n'y a pas assez d'entropie.
L'auteur de l'article prétend que ce n'est pas un problème. Mais ce n'est pas ce que pense l'auteur de la proposition de nouveau RNG, qui considère que la sécurité actuelle est insuffisante. La question n'est pas aussi tranchée que l'article semble le dire.
Ce qui est vrai, c'est que pour la plupart des applications, /dev/urandom est largement suffisant. Mais il y a des usages, minoritaires mais importants, où la possibilité de retomber sur une génération uniquement pseudo-aléatoire (typiquement, au démarrage du système) peut poser de réels problèmes de sécurité.
Et puisque tu parles de getrandom, voilà ce que dit l’auteur de l’article
Oui, et je ne vois pas en quoi cela contredit ce que j'ai dit. getrandom() a un comportement différent de /dev/urandom/ pendant le démarrage du système.
Ainsi (page de manuel de getrandom()) :
By default, when reading from /dev/random, getrandom() blocks if no random bytes are available, and when reading from /dev/urandom, it blocks if the entropy pool has not yet been initialized.
=> au démarrage du système, getrandom() bloque jusqu'à ce que le pool d'entropie soit initialisé (i.e. rempli une première fois)
Tandis que (page de manuel de /dev/urandom):
A read from the /dev/urandom device will not block waiting for more entropy. If there is not sufficient entropy, a pseudorandom number generator is used to create the requested bytes. As a result, in this case the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.
=> au démarrage du système, il est possible que /dev/urandom renvoie des bits théoriquement prédictibles.
Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.
[^] # Re: À propos de /dev/urandom
Posté par Antoine . En réponse à la dépêche Sortie du noyau Linux 4.9. Évalué à 10.
La différence n'est pas là. La différence est dans le fait que
/dev/randomest bloquant jusqu'à ce qu'il y ait assez d'entropie (garantissant ainsi que les bits renvoyés ne peuvent être prédits), alors que/dev/urandompeut renvoyer des bits uniquement pseudo-aléatoires (donc théoriquement prédictibles) s'il n'y a pas assez d'entropie.L'auteur de l'article prétend que ce n'est pas un problème. Mais ce n'est pas ce que pense l'auteur de la proposition de nouveau RNG, qui considère que la sécurité actuelle est insuffisante. La question n'est pas aussi tranchée que l'article semble le dire.
Ce qui est vrai, c'est que pour la plupart des applications,
/dev/urandomest largement suffisant. Mais il y a des usages, minoritaires mais importants, où la possibilité de retomber sur une génération uniquement pseudo-aléatoire (typiquement, au démarrage du système) peut poser de réels problèmes de sécurité.Oui, et je ne vois pas en quoi cela contredit ce que j'ai dit.
getrandom()a un comportement différent de/dev/urandom/pendant le démarrage du système.Ainsi (page de manuel de
getrandom()) :=> au démarrage du système,
getrandom()bloque jusqu'à ce que le pool d'entropie soit initialisé (i.e. rempli une première fois)Tandis que (page de manuel de
/dev/urandom):=> au démarrage du système, il est possible que
/dev/urandomrenvoie des bits théoriquement prédictibles.Encore une fois, l'article pense que cette différence n'a pas d'importance, l'auteur de la proposition de nouveau RNG (et aussi l'auteur des pages de manuel Linux) pense que si.