Oh my. Apparently, AMD CPUs will sometimes return bad results from RDRAND after a suspend. That's bad, but if everyone has been following the cryptographer's advice and _just used getrandom()_ that's not a problem.
... nope! systemd of course didn't!
Conversation
Replying to
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)
2
1
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.
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.
1
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
Show replies