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!https://github.com/systemd/systemd/issues/11810#issuecomment-489727505 …
-
-
I don't have the energy right now to lobby for just replacing /dev/random with a version of /dev/urandom that just blocks on boot, and to make the silly-blocking flag to getrandom() a no-op, but I will sign a support letter if you do!
-
I'll take signatures, but I'm pushing for more; I wouldn't even block on boot is what I'm saying. I'd burn a kernel thread for a few microseconds super early in the boot phase.
End of conversation
New conversation -
-
-
I guess I'm saying that RDRAND-ing in 256-bits of noise, plus another 256-bits of bit-flipping, plus clock time, plus any host IDs, is really "enough" to get going. I'd generate my private RSA key from that, and not lose any sleep.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
PHP solved this problem by having unambiguous APIs that wrap getrandom. random_bytes(integer) returns a string of bytes. random_int(min, max) returns a uniformly random integer. If your OS is totally hosed, they throw an exception instead of weak randomness.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.