4 ms·

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't. (2) Unlike getrandom(), you don't have to read the long section on "Interruption by a signal handler" or know about the special-casing for small buffers or even think about what to put in the flags argument -- getentropy() doesn't have a flags argument. (3) Performance is a bit better than opening /dev/urandom, reading some bytes, and closing the fd, and you don't have to be careful about making sure the fd gets closed no matter the control flow. Performance is probably similar to keeping a persistent /dev/urandom fd open, except that has its own minor hygienic issues (especially in library code or multithreaded code). There are a lot fewer error-checking steps in one call to getentropy() than in opening, reading, and closing /dev/urandom. (4) getentropy() and getrandom() are available even if /dev isn't available or whatever (like in a sandbox, etc.)

lvh 9y ago
Sure. FWIW, my favorite is APIs like Python's os.urandom which just always does the right thing already (including, IIRC, in very recent versions, getentropy()/getrandom()/arc4random_buf() or whatever where available). I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-platform (dev on macOS, deploy on Linux: super common) so I'm pretty comfortable with it still being the default. Maybe not in the 2020 version -- we'll see. I mean sure you can run out of fds and maybe /dev/urandom isn't (1, 9) but if those things happen you're already on your last legs :-)
- deathanatos 9y ago
  If you have a modern version of Python, you can do: import secrets secrets.token_bytes() # returns a randomized token You can pass in the number of bytes you want, but I would think it would be better to rely on the default (presently 256 bit). This module is intended for cryptographic purposes. There are also helper functions to get a hex string or a URL safe string back. https://docs.python.org/3/library/secrets.html https://docs.python.org/3/library/secrets.html
deleted 9y ago
[deleted]
loup-vaillant 9y ago
I may have to update my manual, which currently recommends getrandom() on Linux, and arc4random_buf() on BSD. https://monocypher.org/manual/#Random_number_generation https://monocypher.org/manual/#Random_number_generation On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.
- deleted 9y ago
  [deleted]
- justincormack 9y ago
  It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.
  - deathanatos 9y ago
    getentropy(2) exists on Linux. I do not know when it was introduced, but my Arch system has it. (I feel as if your comment implies that it is the BSD equivalent to getrandom(2).)
    - loeg 9y ago
      OpenBSD introduced getentropy(2). Since it is a subset of getrandom(2) functionality, glibc added a compatibility wrapper that provides the same ABI. (FreeBSD only recently added the getrandom(2) syscall and getentropy(3) libc wrapper functions in -CURRENT.)
    - jwilk 9y ago
      The getentropy() function first appeared in glibc 2.25. http://man7.org/linux/man-pages/man3/getentropy.3.html http://man7.org/linux/man-pages/man3/getentropy.3.html
masklinn 9y ago
> It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't. It could even do that for urandom already. IIRC that's what BSDs do.
- loeg 9y ago
  > It could even do that for urandom already. It could, in the sense that anything is possible, but that isn't the behavior the Linux kernel community has chosen. And they are pretty good about not changing published interfaces at this point. At least getrandom(2) provides the sane behavior (and does not require an fd or filesystem namespace access). > IIRC that's what BSDs do. Yep, at least FreeBSD.

lvh 9y ago

Sure. FWIW, my favorite is APIs like Python's os.urandom which just always does the right thing already (including, IIRC, in very recent versions, getentropy()/getrandom()/arc4random_buf() or whatever where available). I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-platform (dev on macOS, deploy on Linux: super common) so I'm pretty comfortable with it still being the default. Maybe not in the 2020 version -- we'll see. I mean sure you can run out of fds and maybe /dev/urandom isn't (1, 9) but if those things happen you're already on your last legs :-)

deathanatos 9y ago
If you have a modern version of Python, you can do: import secrets secrets.token_bytes() # returns a randomized token You can pass in the number of bytes you want, but I would think it would be better to rely on the default (presently 256 bit). This module is intended for cryptographic purposes. There are also helper functions to get a hex string or a URL safe string back. https://docs.python.org/3/library/secrets.html https://docs.python.org/3/library/secrets.html

deleted 9y ago

[deleted]

loup-vaillant 9y ago

I may have to update my manual, which currently recommends getrandom() on Linux, and arc4random_buf() on BSD. https://monocypher.org/manual/#Random_number_generation https://monocypher.org/manual/#Random_number_generation On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.

deleted 9y ago
[deleted]
justincormack 9y ago
It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.
- deathanatos 9y ago
  getentropy(2) exists on Linux. I do not know when it was introduced, but my Arch system has it. (I feel as if your comment implies that it is the BSD equivalent to getrandom(2).)
  - loeg 9y ago
    OpenBSD introduced getentropy(2). Since it is a subset of getrandom(2) functionality, glibc added a compatibility wrapper that provides the same ABI. (FreeBSD only recently added the getrandom(2) syscall and getentropy(3) libc wrapper functions in -CURRENT.)
  - jwilk 9y ago
    The getentropy() function first appeared in glibc 2.25. http://man7.org/linux/man-pages/man3/getentropy.3.html http://man7.org/linux/man-pages/man3/getentropy.3.html

masklinn 9y ago

> It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't. It could even do that for urandom already. IIRC that's what BSDs do.

loeg 9y ago
> It could even do that for urandom already. It could, in the sense that anything is possible, but that isn't the behavior the Linux kernel community has chosen. And they are pretty good about not changing published interfaces at this point. At least getrandom(2) provides the sane behavior (and does not require an fd or filesystem namespace access). > IIRC that's what BSDs do. Yep, at least FreeBSD.