3 ms·

> Summarizing the article, `cat /dev/random` will still work but will never block `cat /dev/random` may still block, but only once per reboot. It may block if

by gioele 7y ago

> Summarizing the article, `cat /dev/random` will still work but will never block `cat /dev/random` may still block, but only once per reboot. It may block if it is called so early that not enough entropy has been gathered yet. Once there enough entropy has been gathered it will never block again.

simias 7y ago
As mentioned by the article that's already the default behaviour of getrandom() and the BSDs have symlinked /dev/random to /dev/urandom for a long time already. I think this is a change for the best, in particular this bit sounds completely true to my ears: > Theodore Y. Ts'o, who is the maintainer of the Linux random-number subsystem, appears to have changed his mind along the way about the need for a blocking pool. He said that 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". He, too, is concerned that providing a TRNG mechanism will just serve as an attractant for application developers. He also thinks that it is not really possible to guarantee a TRNG in the kernel, given all of the different types of hardware supported by Linux. Even making the facility only available to root will not solve the problem: Application programmers would give instructions requiring that their application be installed as root to be more secure, "because that way you can get access the _really_ good random numbers". The number of time I've had to deal with security-related software and scripts who insisted in sampling /dev/random and stalling for minutes at a time...
- JdeBP 7y ago
  A minor note: * Only FreeBSD symbolically links, and it does it in the other direction. urandom is the symbolic link to random. * OpenBSD has four distinct character device files: random, arandom, srandom, and urandom. * NetBSD (as of 2019) has two distinct character device files: random and urandom. They have different semantics from each other. https://netbsd.gw.com/cgi-bin/man-cgi?rnd+4+NetBSD-current https://netbsd.gw.com/cgi-bin/man-cgi?rnd+4+NetBSD-current
  - aquabeagle 7y ago
    On OpenBSD: $ ls -l /dev/*random* lrwxr-xr-x 1 root wheel 7 Dec 10 15:05 /dev/random@ -> urandom crw-r--r-- 1 root wheel 45, 0 Jan 6 15:30 /dev/urandom
    - JdeBP 7y ago
      That must be a recent change. $ ls -F /dev/*random* /dev/arandom /dev/random /dev/srandom /dev/urandom $
      - ben_bai 7y ago
        Deleted in 2017. https://marc.info/?l=openbsd-cvs&m=151069089605712&w=2 https://marc.info/?l=openbsd-cvs&m=151069089605712&w=2 you can delete arandom and srandom Edit: better link
- guenthert 7y ago
  And you don't think they did so for a reason? If you don't care for security (and there are good reason why one wouldn't), then you can create the link yourself on those systems (or link to /dev/zero for extra low wait times). Why does now everyone have to suffer the same? What happened to "keep policy out of the kernel"?

by gioele 7y ago

simias 7y ago

As mentioned by the article that's already the default behaviour of getrandom() and the BSDs have symlinked /dev/random to /dev/urandom for a long time already. I think this is a change for the best, in particular this bit sounds completely true to my ears: > Theodore Y. Ts'o, who is the maintainer of the Linux random-number subsystem, appears to have changed his mind along the way about the need for a blocking pool. He said that 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". He, too, is concerned that providing a TRNG mechanism will just serve as an attractant for application developers. He also thinks that it is not really possible to guarantee a TRNG in the kernel, given all of the different types of hardware supported by Linux. Even making the facility only available to root will not solve the problem: Application programmers would give instructions requiring that their application be installed as root to be more secure, "because that way you can get access the _really_ good random numbers". The number of time I've had to deal with security-related software and scripts who insisted in sampling /dev/random and stalling for minutes at a time...

JdeBP 7y ago
A minor note: * Only FreeBSD symbolically links, and it does it in the other direction. urandom is the symbolic link to random. * OpenBSD has four distinct character device files: random, arandom, srandom, and urandom. * NetBSD (as of 2019) has two distinct character device files: random and urandom. They have different semantics from each other. https://netbsd.gw.com/cgi-bin/man-cgi?rnd+4+NetBSD-current https://netbsd.gw.com/cgi-bin/man-cgi?rnd+4+NetBSD-current
- aquabeagle 7y ago
  On OpenBSD: $ ls -l /dev/*random* lrwxr-xr-x 1 root wheel 7 Dec 10 15:05 /dev/random@ -> urandom crw-r--r-- 1 root wheel 45, 0 Jan 6 15:30 /dev/urandom
  - JdeBP 7y ago
    That must be a recent change. $ ls -F /dev/*random* /dev/arandom /dev/random /dev/srandom /dev/urandom $
    - ben_bai 7y ago
      Deleted in 2017. https://marc.info/?l=openbsd-cvs&m=151069089605712&w=2 https://marc.info/?l=openbsd-cvs&m=151069089605712&w=2 you can delete arandom and srandom Edit: better link
guenthert 7y ago
And you don't think they did so for a reason? If you don't care for security (and there are good reason why one wouldn't), then you can create the link yourself on those systems (or link to /dev/zero for extra low wait times). Why does now everyone have to suffer the same? What happened to "keep policy out of the kernel"?