> Date: Sun, 22 Dec 2019 01:27:58 +0000 > From: <[email protected]> > > > On Dec 21, 2019, at 5:08 PM, Taylor R Campbell <[email protected]> wrote: > > - For (e.g.) keyboard interrupt and network packet timings, this > > is zero, because an adversary can cause events to happen with > > timing that leads to predictable samples entering the pool. > > That seems overly pessimistic, depending on the timer resolution. > If you have a CPU cycle timer, then it is perfectly reasonable to > claim a bit or two of entropy, since an adversary doesn't have the > ability to control the timing of those events to nanosecond > accuracy, nor the ability to control internal processing delays > (like memory cache misses) which introduce variability way in excess > of a CPU cycle.
When I'm typing, there might be nonzero entropy in the cycle counts between keystrokes on my 2.3 GHz laptop. But I don't have a good model, justified by physics, for the probability distribution on the differences in cycle counts. And I definitely don't have one that works for all keyboards on all types of buses on all machines under all typing styles by all adversaries, including my cat sleeping on my keyboard. Do you? We can wave hands about cache misses, but adversaries often have a lot of avenues for influencing the microarchitectural state of the CPU via, e.g., network packets that trigger specific code paths. So I'm not willing to commit to higher entropy estimates for something that was never designed to be unpredictable in the first place unless there's a confidence-inspiring argument -- involving physics and engineering of the hardware -- to justify it. This may well be pessimistic. It would be great if we could make better promises to users -- but only if we can be honest in those promises. Right now we are trading honesty for expediency. My hope is that, for most users, everything else in this change and other recent changes will render moot the motivation for that bargain in the first place. Of course, driver authors have also taken claims by various hardware RNG vendors at face value: - Sometimes they are at least backed up by design documents, like the Intel RDRAND/RDSEED. - Sometimes they are backed up by external audits, like the VIA C3 XSTORE RNG. - Sometimes they are just opaque device registers or DMA commands and you have to do science on them yourself, like the Allwinner Sun8i Crypto Engine TRNG, which seems to have at most 1 bit of min-entropy for every 100 bits of data (and is currently disabled by default until I have a better idea of what to expect from it). What can I honestly promise works? Flip a coin 256 times and run `echo httttthhthhhthhhtttt... >> /dev/random'; then the random seed management of rndctl should take care of you for the foreseeable future. Of course, most users don't have the patience for that. Fortunately, most users do not have Intel in their threat model; for those users it is reasonable to rely on Intel RDRAND/RDSEED, for instance.
