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
Now I'm kind of scared to go look what genuine_random_bytes does...
OK, WTF, what is pseudo randomness exactly, and why on earth would you want some "genuine" randomness with a splash of "pseudo" on top.
github.com/systemd/system
6
20
117
Oh... oh.
Pseudo-randomness is literally rand(). You know, the predictable one. Not some AES-CTR thing. Literally rand().
WHY WOULD YOU EVER WANT HALF CRYPTO AND HALF PREDICTABLE RANDOMNESS.
github.com/systemd/system
11
48
160
Oh, that's why. Because the entropy bowl might be empty!
The amount of damage the Linux kernel might have made by convincing everyone entropy somehow magically runs out is incalculable.
6
69
216
Replying to
There has been so much contradicting info on /dev/urandom vs. /dev/random, and I am just recently learning that I can actually use urandom for stuff that really needs to be random. The
blocking behaviour of /dev/random hints that its entropy is better quality and thus for crypto
3
11
You should always just use getrandom in the default mode, which never blocks once the CSPRNG has been initialized in early boot. It's the same CSPRNG as /dev/urandom but with one-time blocking in early boot until it has at least 128 bits of entropy.