These seem like really good mitigations to make a userland RNG safe. But makes me wonder why they don’t just use a kernel RNG.https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/ …
-
-
Replying to @matthew_d_green
Reason 1: speed, we (and OpenSSL, BoringSSL, etc ...) have per-thread RNGs to avoid lock contention (either in user-space or the kernel). Matters most for per-record explicit IVs and hello messages. Recent improvements in Linux and libc perf should fix this.
2 replies 1 retweet 6 likes -
Replying to @colmmacc @matthew_d_green
Reason 2: In-kernel RNGs have been their own poorly audited moving target, getting better though!
2 replies 1 retweet 1 like -
Replying to @colmmacc
The third mitigation still seems to rely on kernel support, so it still seems like auditing and replacing the kernel RNG is in scope.
1 reply 0 retweets 0 likes -
Replying to @matthew_d_green
For now it's easier - Linux won't break a userspace guarantee, so madvise option is reliable, but an SP800-90A DRBG may come to Linux soon in the form of http://www.chronox.de/lrng.html , http://www.chronox.de/lrng/doc/lrng.pdf …
1 reply 0 retweets 1 like -
Replying to @colmmacc
I hope they do HMAC and not CTR. I think using invertible functions for RNGs is a dangerous idea. Too easy to break the rekeying logic and get a beautiful backdoor.
1 reply 2 retweets 3 likes -
Replying to @matthew_d_green
HMAC is considerably slower, even with SHA extensions, and Prediction Resistance is supposed to mitigate that, which is how all of the implementations so far have settled on AES_CTR or ChaCha20.
2 replies 1 retweet 0 likes
I'd love to see a new DRBG algorithm though that uses HMAC or HKDF, includes fast-key-erasure (as DJB calls it), and has test vectors etc. The more recent NRBG definitions from SP800-90C seem awful, no use at all.
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.