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
Replying to
/dev/random should not exist, and it doesn't (in its blocking for no reason form) on any system except Linux.
3
16
It can be turned into a symlink to urandom or device referencing it though. The only issue is that the one-time blocking on init is only implemented for getrandom and not urandom, which it should be, and broken VMs should just start passing proper init entropy to the OS.