J’en profite pour repartager Myths about /dev/urandom (cette fois Zenitram ne pourra plus me traiter de « fan de Trump » parce que je partage ce lien).
Cet article est à prendre avec des pincettes, il prend pas mal de raccourcis et il me semble contredire les propos du mainteneur de LRNG.
L'auteur de ce site a oublié certains problèmes autour de /dev/urandom.
Il a fallu y ajouter un spinlock, parce que lorsque plusieurs processus interrogeaient ce device, ils pouvaient recevoir un jeu de de données similaire.Puis, pour éviter les embouteillages, on a créé autant de réserves derrière urandom qu'il y a de noeuds NUMA … quand il y en a.
Enfin, il suffit de lire les discussions lors de la sortie de la 5.3 en octobre dernier pour voir que cette situation est assez complexe.
Depuis l'introduction du syscall getrandom() dans 3.17, puis des implémentations de getentropy() et getrandom() dans la glibc 2.25, il y a eu pas mal de chemin parcouru.
Ceci dit, linux semble se rapprocher des implémentations BSD (notamment Open), qui n'ont jamais bloqué. (urandom est un lien vers random sous freeBSD ).
Cet article est à prendre avec des pincettes, il prend pas mal de raccourcis et il me semble contredire les propos du mainteneur de LRNG.
C’est un article de vulgarisation, bien sûr qu’il prend des raccourcis, ça ne veut pas dire qu’il est faux. Le fait qu’il contredise les mainteneurs de Linux, non plus d’ailleurs (ils sont humains, ils peuvent aussi se tromper).
D’ailleurs, cet article est cité par plusieurs personnes assez connu dans le monde de la cryptographie, par exemple dans la conférence The plain simple reality of entropy de Filippo Valsorda (même si personnellement je ne l’apprécie pas particulièrement, on peut pas dire que ce soit un inconnu).
Dans le même genre tu as On Linux's Random Number Generation de Thomas Pornin, qui en plus d’être « moins technique », est beaucoup plus critique vis à vis du fonctionnement dans Linux (et l’article est bien plus récent).
Je ne vois pas trop où se trouve la vulgarisation ici.
bien sûr qu’il prend des raccourcis
ça ne veut pas dire qu’il est faux
Et donc, c'est qu'il dit vrai ?
D’ailleurs, cet article est cité par plusieurs personnes assez connu dans le monde de la cryptographie […] Filippo Valsorda
'connais pas.
Dans le même genre tu as On Linux's Random Number Generation de Thomas Pornin,
Justement, cet article contredit en plusieurs point le précédent.
qui en plus d’être « moins technique »,
Au contraire, il est technique.
est beaucoup plus critique vis à vis du fonctionnement dans Linux
Évidemment, c'est un dev OpenBSD. C'est même l'auteur de crypto/aes si je ne me trompe pas.
D'ailleurs vous retrouverez ce point de vue dans les commentaires et les ml linux sur le sujet:
«Later on, a system call was added, to get randomness without having to open a file and use a file descriptor;
it is named getrandom(). That system call finally implements the proper behavior,
i.e. blocking until a sufficient amount of initial entropy has been gathered since last boot, but never blocking afterwards.
Incidentally, this is what /dev/urandom does on sane systems (e.g. FreeBSD or macOS). Applications should simply use getrandom(), and be happy.»
A mettre en lien avec ce commentaire du mainteneur de LRNG:
«removing that pool would effectively get rid of the idea that Linux has a true random-number generator (TRNG), which "is not insane; this is what the *BSD's have always done"»
# Myths about /dev/urandom
Posté par Anonyme . Évalué à 4.
J’en profite pour repartager Myths about /dev/urandom (cette fois Zenitram ne pourra plus me traiter de « fan de Trump » parce que je partage ce lien).
[^] # Re: Myths about /dev/urandom
Posté par David Marec . Évalué à 5.
Cet article est à prendre avec des pincettes, il prend pas mal de raccourcis et il me semble contredire les propos du mainteneur de LRNG.
L'auteur de ce site a oublié certains problèmes autour de
/dev/urandom.Il a fallu y ajouter un
spinlock, parce que lorsque plusieurs processus interrogeaient ce device, ils pouvaient recevoir un jeu de de données similaire.Puis, pour éviter les embouteillages, on a créé autant de réserves derrièreurandomqu'il y a de noeuds NUMA … quand il y en a.Enfin, il suffit de lire les discussions lors de la sortie de la 5.3 en octobre dernier pour voir que cette situation est assez complexe.
Depuis l'introduction du syscall
getrandom()dans 3.17, puis des implémentations degetentropy()etgetrandom()dans la glibc 2.25, il y a eu pas mal de chemin parcouru.Ceci dit, linux semble se rapprocher des implémentations BSD (notamment Open), qui n'ont jamais bloqué. (
urandomest un lien versrandomsous freeBSD ).[^] # Re: Myths about /dev/urandom
Posté par Anonyme . Évalué à 3.
C’est un article de vulgarisation, bien sûr qu’il prend des raccourcis, ça ne veut pas dire qu’il est faux. Le fait qu’il contredise les mainteneurs de Linux, non plus d’ailleurs (ils sont humains, ils peuvent aussi se tromper).
D’ailleurs, cet article est cité par plusieurs personnes assez connu dans le monde de la cryptographie, par exemple dans la conférence The plain simple reality of entropy de Filippo Valsorda (même si personnellement je ne l’apprécie pas particulièrement, on peut pas dire que ce soit un inconnu).
Dans le même genre tu as On Linux's Random Number Generation de Thomas Pornin, qui en plus d’être « moins technique », est beaucoup plus critique vis à vis du fonctionnement dans Linux (et l’article est bien plus récent).
[^] # Re: Myths about /dev/urandom
Posté par David Marec . Évalué à 3.
Je ne vois pas trop où se trouve la vulgarisation ici.
Et donc, c'est qu'il dit vrai ?
'connais pas.
Justement, cet article contredit en plusieurs point le précédent.
Au contraire, il est technique.
Évidemment, c'est un dev OpenBSD. C'est même l'auteur de crypto/aes si je ne me trompe pas.
D'ailleurs vous retrouverez ce point de vue dans les commentaires et les ml linux sur le sujet:
«Later on, a system call was added, to get randomness without having to open a file and use a file descriptor;
it is named getrandom(). That system call finally implements the proper behavior,
i.e. blocking until a sufficient amount of initial entropy has been gathered since last boot, but never blocking afterwards.
Incidentally, this is what /dev/urandom does on sane systems (e.g. FreeBSD or macOS). Applications should simply use getrandom(), and be happy.»
A mettre en lien avec ce commentaire du mainteneur de LRNG:
«removing that pool would effectively get rid of the idea that Linux has a true random-number generator (TRNG), which "is not insane; this is what the *BSD's have always done"»
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.