• # Myths about /dev/urandom

    Posté par  (site Web personnel) . É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  (site Web personnel) . É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è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 ).

      • [^] # Re: Myths about /dev/urandom

        Posté par  (site Web personnel) . Évalué à 3.

        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).

        • [^] # Re: Myths about /dev/urandom

          Posté par  (site Web personnel) . Évalué à 3.

          C’est un article de vulgarisation,

          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"»

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.