Colm are you being sarcastic.
Conversation
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.
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
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
RDRAND is *substantially* slower than that, so what is the use case supposed to be? I think the only actual reason for it existing is that it keeps the CSPRNG state out of the address space, but it's completely useless in practice since it fails unexpectedly, not just like this.
It's useful for seeding the kernel CSPRNG, but for whatever reason there's the separate RDSEED instruction for that. I can't really see an *actual* use case for RDRAND other than that due to poor performance (high latency, low throughput) + failures in cases like heavy threading.