Who predicted RDRAND would be buggy? Everybody? Yet there's still tons of code that relies on it working. RDRAND is OK as *an* entropy source for a CSPRNG. It can't be the only entropy source. Blacklisting the known-bad AMD CPUs is not a solution. What about the unknown-bad CPUs?
-
Show this thread
-
Theodore Ts'o (曹子德) famous comment about how he insisted on doing it the right way in Linux: https://news.ycombinator.com/item?id=6336505 . I'm still hoping to find a good design for a getrandom()-like mechanism for SGX & similar that don't have any obvious entropy source other than RDRAND.
1 reply 3 retweets 11 likesShow this thread
Replying to @BRIAN_____
AES-CTR-DRBG seeded with time, any cpu/host/process/thread-ids available, a personalization string, for(i = 0; i < 256; I++) { bit = flip_bit_for_one_microsecond(); i++); , then mix in RDRAND on each invocation?
9:42 PM - 28 Jun 2019
0 replies
0 retweets
1 like
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.