26 ms·

Forget whether you "roll your own" or not, userspace RNGs are a bad idea. The advice to rely on getrandom or urandom is as much about the superior security prop

by tptacek 1mo ago

Forget whether you "roll your own" or not, userspace RNGs are a bad idea. The advice to rely on getrandom or urandom is as much about the superior security properties of a kernel RNG as they are about whether you'll fuck up AES somehow.

strenholme 1mo ago
Linux kernel crypto code has resulted in security issues, e.g. CVE-2026-31431. The advantage of using a cryptographically secure stream cipher [1] is that we only need about 128-256 bits of good entropy to generate an arbitrary large number of secure random numbers, across multiple systems (e.g. MaraDNS has a native Windows port where /dev/urandom randomness is instead done with proprietary Windows API calls). It can even give us some level of protection on systems where the OS level random API is compromised: Some people are wary of RDRAND because they think Intel might actually use an insecure PRNG for the numbers, and Coldcard Bitcoin seed generators were compromised a little over a month ago because their version of /dev/urandom was completely insecure on some of their devices. [1] Yes, libsodium supports them: https://libsodium.gitbook.io/doc/advanced/stream_ciphers https://libsodium.gitbook.io/doc/advanced/stream_ciphers
- tptacek 1mo ago
  This is CopyFail. You just provided CopyFail as evidence in favor of userspace random number generators.
nly 1mo ago
A read() on /dev/urandom on every packet isn't economical, so there's going to be some user space element to RNGion
- tptacek 1mo ago
  I don't grant the premise that per-transaction urandom reads are likely a meaningful expense to begin with but on modern Linux getrandom is a vDSO anyways. Even before the vDSO, getrandom was fast. The application domain where this tends to get brought up as a problem is in large-scale simulation. I have no opinion about whether getrandom is fast enough for simulation, but here we're talking about cryptographic random numbers, not simply high-quality random numbers. If you want to use something like PCG for your simulations I won't dunk on you.
- strenholme 1mo ago
  In addition to the overhead of a /dev/urandom read(), since my programs run in a chroot() sandbox, there’s the possibility that the file descriptor to /dev/urandom will no longer function—since chroot() is not part of POSIX, there’s no rigorous standard on how chroot() is supposed to behave with a given operating system. getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX. The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()). This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS. Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.
  - tptacek 1mo ago
    I don't think trading resilience for POSIX compliance is a good call, and I don't think "strong random numbers" is at all the right way to think about this problem.

by tptacek 1mo ago

strenholme 1mo ago

Linux kernel crypto code has resulted in security issues, e.g. CVE-2026-31431. The advantage of using a cryptographically secure stream cipher [1] is that we only need about 128-256 bits of good entropy to generate an arbitrary large number of secure random numbers, across multiple systems (e.g. MaraDNS has a native Windows port where /dev/urandom randomness is instead done with proprietary Windows API calls). It can even give us some level of protection on systems where the OS level random API is compromised: Some people are wary of RDRAND because they think Intel might actually use an insecure PRNG for the numbers, and Coldcard Bitcoin seed generators were compromised a little over a month ago because their version of /dev/urandom was completely insecure on some of their devices. [1] Yes, libsodium supports them: https://libsodium.gitbook.io/doc/advanced/stream_ciphers https://libsodium.gitbook.io/doc/advanced/stream_ciphers

tptacek 1mo ago
This is CopyFail. You just provided CopyFail as evidence in favor of userspace random number generators.

nly 1mo ago

A read() on /dev/urandom on every packet isn't economical, so there's going to be some user space element to RNGion

tptacek 1mo ago
I don't grant the premise that per-transaction urandom reads are likely a meaningful expense to begin with but on modern Linux getrandom is a vDSO anyways. Even before the vDSO, getrandom was fast. The application domain where this tends to get brought up as a problem is in large-scale simulation. I have no opinion about whether getrandom is fast enough for simulation, but here we're talking about cryptographic random numbers, not simply high-quality random numbers. If you want to use something like PCG for your simulations I won't dunk on you.
strenholme 1mo ago
In addition to the overhead of a /dev/urandom read(), since my programs run in a chroot() sandbox, there’s the possibility that the file descriptor to /dev/urandom will no longer function—since chroot() is not part of POSIX, there’s no rigorous standard on how chroot() is supposed to behave with a given operating system. getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX. The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()). This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS. Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.
- tptacek 1mo ago
  I don't think trading resilience for POSIX compliance is a good call, and I don't think "strong random numbers" is at all the right way to think about this problem.