4 ms·
> In practice, /dev/urandom advocacy has won for almost all apps. Which is a shame, because the thing that should've won is arc4random_buf or something simila
by clarry 7y ago
> In practice, /dev/urandom advocacy has won for almost all apps.
Which is a shame, because the thing that should've won is arc4random_buf or something similar that always works (empty chroot with no /dev/ under it, isolated user with no read access to anything on the filesystem, and no free file descriptors? still works!) and can't give an error.
- acqq 7y agogetrandom should be used: https://lwn.net/Articles/606141/ https://lwn.net/Articles/606141/ for most user code it's already good enough, the breakage happened in some early use cases: https://lwn.net/Articles/800509/ https://lwn.net/Articles/800509/
- ajross 7y agoFor clarity: I'm using "/dev/urandom" as shorthand for "the non-blocking interface to the kernel entropy pool" and not the literal device node interface. As others have pointed out there is a syscall to get that for you if you can't use the device.
- tytso 7y agoTo be completely correct: On modern kernels, /dev/urandom is not an interface to the kernel entropy pool. It is rather a ChaCha20 Cryptographic Random Number Generator which is periodically seeded from the kernel entropy pool. getrandom(2) uses the same ChaCha20-based CRNG. The main advantage is that it doesn't require that you be able to open a file descriptor. (There were some obscure attacks on some userspace where the attacker would exhaust the number of file descriptors, and the sloppy userspace code wasn't checking error returns, and so it wasn't actually reading from /dev/urandom. Getrandom(2) is supposed to be foolproof --- which is hard, given how ingenious fools can be, but at least it's harder to screw up using getrandom(2). It also works in the completely empty chroot scenario referenced in the grandparent of this post.