,
12 tweets,
4 min read
Read on Twitter
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!
github.com/systemd/system…
... nope! systemd of course didn't!
github.com/systemd/system…
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…
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…
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…
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…
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.
The amount of damage the Linux kernel might have made by convincing everyone entropy somehow magically runs out is incalculable.
So inconsiderate for the caller to insist on good data.
Anyway, the reason we were in this sadness pit in the first place was to find out why they'd use straight RDRAND.
And there it is.
Not to waste the precious mythical entropy-that-runs-out, this legendary silver coloured fluid that leaks from pools.
ENTROPY👏DOES👏NOT👏RUN👏OUT
And there it is.
Not to waste the precious mythical entropy-that-runs-out, this legendary silver coloured fluid that leaks from pools.
ENTROPY👏DOES👏NOT👏RUN👏OUT
But Filippo, I'm sure these are all just misguided perf optimizations and that the defaults use the set of flags equivalent to getrandom()…
Nah. random_bytes will use straight RDRAND, fall back on a single getrandom() call, and fill the rest with rand().
(╯°□°)╯︵ ┻━┻
Nah. random_bytes will use straight RDRAND, fall back on a single getrandom() call, and fill the rest with rand().
(╯°□°)╯︵ ┻━┻
Bonus: apparently not even holding RDRAND right.
NOT THAT IT SHOULD MATTER, because nothing general-purpose in userspace should ever touch RDRAND and instead USE getrandom() and fall back to urandom.
NOT THAT IT SHOULD MATTER, because nothing general-purpose in userspace should ever touch RDRAND and instead USE getrandom() and fall back to urandom.
I really have no horse in the PID 1 races, but Poettering is now insulting me on Twitter, so I guess I know where I stand on interacting with that community. ¯\_(ツ)_/¯
BTW, I get it, PID 1 can't block at boot (even if that's not the justification the comments give).
Calling getrandom(GRND_NONBLOCK) and falling back to RDRAND from a special MIGHT_BE_INSECURE_EARLY_BOOT_RANDOM function would make sense.
Calling getrandom(GRND_NONBLOCK) and falling back to RDRAND from a special MIGHT_BE_INSECURE_EARLY_BOOT_RANDOM function would make sense.
Instead, the innocently named random_bytes makes a whole mix of secure and insecure sources over three different axes. And unsurprisingly, it ends up being used in security sensitive places, long after boot.
