> Date: Mon, 5 Apr 2021 01:16:56 +0000 (UTC) > From: RVP <r...@sdf.org> > > Then, the issue here is one of predictability. NetBSD doesn't want, > for extremely valid reason, to incorporate any perturbation sources > which have been pooh-poohed in the technical literature.
Why do you say that? We do incorporate many sources that are not well-studied -- every keystroke, for example, and the CPU cycle counter at the time of the keystroke, affects the output of /dev/urandom. We just don't _count_ these sources for the purpose of detecting and reporting the potential security problem of low entropy, because we don't have a good model by which we can confidently claim they are actually unpredictable to an adversary. > Or, perhaps statistical tests of the raw in-kernel sources will > demonstrate exactly why things like timing jitter have been > pooh-poohed in the literature? What do you mean by `things like timing jitter have been pooh-poohed in the literature'? Timing jitter in ring oscillators arising from thermal noise in the silicon is the main source of entropy in most on-die hardware RNGs on the market that I'm aware of. This design is reasonably well-studied in the literature. We even try to use something like it by default in NetBSD when nothing else is available -- we use the periodic hardclock interrupt timer to sample the CPU cycle counter, in the hope that these clocks are driven by independent oscillators with some timing jitter. However, this is a generic mechanism that works on any machine -- and on some machines, there is no CPU cycle counter so it might fall back to using the hardclock timer as a substitute, defeating the purpose. And even if there is a CPU cycle counter, it might be clocked by the same oscillator as the hardclock timer, &c. So we conservatively count the hardclock entropy source as having zero entropy.