I think you're misreading the source here. Systemd _does_ call getrandom() if the syscall is available + adds an RDRAND seed on top (if explicitly enabled)
and only pads with pseudorandom bytes if getrandom() returns EGAIN (no entropy)
Conversation
Replying to
I am staring at it, and I can't see how RANDOM_ALLOW_RDRAND does not lead to plain RDRAND output, which is apparently what caused the user-reported issue.
2
2
There'd be no real harm in generating 256 bits of entropy by doing the dirty "flip a bit for approximately 100 nanos and take the final value" trick and mixing that it in. Along with clock values and HWIDs.
2
I'm not! That stuff is 100% safe to mix in to a DRBG, it can't make it any worse, and is defensive when the primary source is broken.
1
That kind of over-thinking is what leads to the code this thread is about. I'm sure you don't consider HASH(time, HWID, bit flip) *sufficient*, but some systemd developer will in the EAGAIN branch.
The message must be "just use getrandom or urandom", which *is* sufficient.
2
1
13
I agree most of the time one probably isn't going to do better than `getrandom()`. I think this advice would be more complete if getrandom had a more complete interface to control prediction resistance and to incorporate additional data (e.g. for ECDSA nonces).
1
1
In my experience, users end up wanting to use the crypto library w/o an OS-provided CSPRNG. This, combined with the limited interface of `getrandom()` does encourage use of an userspace one still.
OTOH, `getrandom()` impl is fast on recent kernels, though that's a trade-off.
1
It has high throughput due to using ChaCha20 but using it still requires a system call and synchronization. It's perfectly usable for many forms of direct usage like generating a key, but there are many uses for a CSPRNG requiring much lower overhead including avoiding locking.
1
One way to do that is a ChaCha implementation seeded from it (and reseeded on fork if applicable) and optionally reseeded at some interval. An example is the OpenBSD arc4random, but that's a global CSPRNG with a lock around it rather than thread-local. Often not fast enough.
1
RDRAND actually has lower throughput than getrandom anywhere that I've tested, but making a system call to getrandom is quite expensive and that dwarfs the costs. In theory, a proper RDRAND would be useful because CSPRNG state isn't in the address space. In practice, it sucks.
It's not very useful for direct usage because it's too slow when overhead matters a lot + isn't portable. I don't really understand why anyone needing very low overhead would actually bother to use RDRAND over ChaCha (including 8/12 round options) seeded/reseeded with getrandom.
1
A ChaCha8 CSPRNG with a small cache seeded / reseeded from getrandom is an incredibly efficient drop-in replacement for non-cryptographically secure random number generators nearly across the board. It's great for uses like entropy in game engines. Might as well use a CSPRNG.
1
Show replies