Hi, I was digging into blocking to read /dev/random to seed the SOSEMANUK cipher on startup, and /dev/urandom and /dev/random, and it seems to be unnecessary use /dev/random and block for a few reasons.
The SOSEMANUK cipher is only used in a single place in the codebase, in bf_random_bytes() in src/numbers.cc.
Since this is only used to expose the random_bytes function inside the MOO, and not for anything that needs cryptographic security, unless someone's implementing cryptographic functions inside of the database using it, using /dev/random is at best overkill.
Using /dev/random can block on server startup for a while, especially on an otherwise inactive server, and using haveged is more of a stopgap solution than a real fix.
Security-wise, the upstream Linux kernel developer consensus seems to be that the underlying CRNG behind /dev/random and /dev/urandom is good enough for cryptography, and that the blocking CRNG at best gives a misleading sense of how random the resulting data is [1], and isn't recommended for most uses, leading to /dev/random becoming like /dev/urandom in Linux versions later than 5.6 [2].
While it was once more widely recommended, current manpages for Linux describe /dev/random as "legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted" [3].
The only situation where /dev/urandom would return less secure data is during very early boot, before the entropy pool is initialized, and it exceedingly unlikely to be running toaststunt during early boot.
In addition, on modern FreeBSD [4] [5], OpenBSD [6], and MacOS [7], /dev/random and /dev/urandom are links to the same thing.
Due to this, we should save a lot of time on startup, without compromising security on reasonably modern systems, even if random_bytes were used in a cryptographic context in some databases.
I hope this isn't overly verbose, but I hope that it's helpful if someone with only a mild (outdated) understanding of /dev/urandom and /dev/random stumbles onto it (like me a few days ago, before I went down a rabbithole).
I apologize if I should add a note in the README that haveged shouldn't be necessary anymore, or that changing the MINIMUM_SEED_ENTROPY isn't needed anymore, or bump the EXT version number.
I instead removed the obsolete references without adding a note in the README because I wasn't sure on the guidelines for whether or not to do so.
Hi, I was digging into blocking to read
/dev/randomto seed the SOSEMANUK cipher on startup, and/dev/urandomand/dev/random, and it seems to be unnecessary use/dev/randomand block for a few reasons.The SOSEMANUK cipher is only used in a single place in the codebase, in
bf_random_bytes()insrc/numbers.cc. Since this is only used to expose the random_bytes function inside the MOO, and not for anything that needs cryptographic security, unless someone's implementing cryptographic functions inside of the database using it, using/dev/randomis at best overkill.Using
/dev/randomcan block on server startup for a while, especially on an otherwise inactive server, and usinghavegedis more of a stopgap solution than a real fix.Security-wise, the upstream Linux kernel developer consensus seems to be that the underlying CRNG behind
/dev/randomand/dev/urandomis good enough for cryptography, and that the blocking CRNG at best gives a misleading sense of how random the resulting data is [1], and isn't recommended for most uses, leading to/dev/randombecoming like/dev/urandomin Linux versions later than 5.6 [2]. While it was once more widely recommended, current manpages for Linux describe/dev/randomas "legacy interface which dates back to a time where the cryptographic primitives used in the implementation of/dev/urandomwere not widely trusted" [3]. The only situation where/dev/urandomwould return less secure data is during very early boot, before the entropy pool is initialized, and it exceedingly unlikely to be running toaststunt during early boot.In addition, on modern FreeBSD [4] [5], OpenBSD [6], and MacOS [7],
/dev/randomand/dev/urandomare links to the same thing.Due to this, we should save a lot of time on startup, without compromising security on reasonably modern systems, even if
random_byteswere used in a cryptographic context in some databases.I hope this isn't overly verbose, but I hope that it's helpful if someone with only a mild (outdated) understanding of
/dev/urandomand/dev/randomstumbles onto it (like me a few days ago, before I went down a rabbithole). I apologize if I should add a note in the README thathavegedshouldn't be necessary anymore, or that changing theMINIMUM_SEED_ENTROPYisn't needed anymore, or bump theEXTversion number. I instead removed the obsolete references without adding a note in the README because I wasn't sure on the guidelines for whether or not to do so.[1] https://lwn.net/Articles/808575/ [2] https://github.com/torvalds/linux/commit/30c08efec8884fb106b8e57094baa51bb4c44e32 [3] https://man7.org/linux/man-pages/man4/random.4.html [4] https://www.freebsd.org/cgi/man.cgi?query=random&apropos=0&sektion=4&manpath=FreeBSD+13.0-current&arch=default&format=html [5] https://github.com/freebsd/freebsd-src/blob/b6be9566d236f83ad1a44170a64b9a34e382eafa/sys/dev/random/randomdev.c#L412 [6] https://man.openbsd.org/random.4 [7] https://www.unix.com/man-page/mojave/4/random