4 ms·

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

by nly 8d ago

tptacek 8d 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 8d 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 8d 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.

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

by nly 8d ago

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

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 8d 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 8d 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.