Good point Ted, I agree we should have a defense-in-depth design that plans on failure. I expect keypoolrandom to be resistant against this attack as well. In this threat model, p' is a Laplacian Demon. Any parallel construction is aided by whatever source of information the attacker can come by. Using jiffies as a known-perimage aids Laplace's Demon, as does a memory disclosure vulnerability. Leplace's Demon can simply "get lucky" and report both false-positives and false-negatives, but in this model it should get more lucky over time. Now we get into the realm of statistics and predictive mathematics, which gets into Langevin Dynamics and Einstein's early work describing Brownian Motion. Looping in a fellow Cryptographer Nicholas, who has a passion for Laplace's work. Regards, Michael On Wed, Mar 30, 2022 at 12:01 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Wed, Mar 30, 2022 at 11:33:21AM -0700, Michael Brooks wrote: > > The /dev/random device driver need not concern itself with root > > adversaries as this type of user has permissions to read and overwrite > > memory - this user even possesses permission to replace the kernel elf > > binary with a copy of /dev/random that always returns the number 0 - > > that is their right. > > The design consideration that random number generators do concern > themselves with is recovery after pool exposure. This could happen > through any number of ways; maybe someone got a hold of the suspended > image after a hiberation, or maybe a VM is getting hybernated, and > then replicated, etc. > > One can argue whether or not it's "reasonable" that these sorts of > attacks could happen, or whether they are equivalent to full root > access whether you can overwrite the pool. The point remains that it > is *possible* to have situations where the internal state of the RNG > might have gotten exposed, and a design criteria is how quickly or > reliably can you reocver from that situation over time. > > See the Yarrow paper and its discussion of iterative guessing attack > for an explanation of why cryptographers like John Kelsey, Bruce > Schneier, and Niels Ferguson think it is important. And please don't > argue with me on this point while discussing which patches should be > backported to stable kernels --- argue with them. :-) > > Cheers, > > - Ted
