Most of the entropy in a system is manifest in terms of the clock skew between direct memory access (DMA) transfers from external devices and the CPU core clocks, which unfortunately does not traverse the kernel in any directly observable manner. By "external", I mean devices relying on separate quartz oscillators, for example plugin USB or perhaps harddisks. Due to bus access arbitration, much of this entropy is actually visible from userspace, especially if the userspace process is taking a much larger time slice than the kernel. (I don't dispute that userspace does not generate entropy. However, it can see much of it indirectly.) In any event, very little entropy is in the form of interrupt timing, unless we extend the definition of "interrupt" to include quasiperiodic memory accesses from external clients. However, from a security perspective, we might be stuck with interrupt timing in isolation because it's unlikely that the engineer implementing the TRNG would be able to quantify the entropy content of the DMA effects on the timestamp stream, even if the latter were sampled in a tight loop. This is unfortunate because it's comparatively rich.
On Fri, May 6, 2016 at 6:02 PM, Krisztián Pintér <[email protected]> wrote: > > > > Russell Leidich (at Friday, May 6, 2016, 7:48:49 PM): > > a "real world" situation, userspace is richer because it's active > > maybe 2 or 3 orders of magnitude more often than the kernel, and so > > can afford to accrue much more timing entropy, some of which is > > bound to be physical in origin. > > userspace does not generate entropy at all. everything that can be > considered entropy goes through the kernel, in form of interrupts or > something. > > grabbing this kind of entropy is very cheap, so i see no reason why > would a kernel not do that. but i might be mistaken, i'm not a hw > expert, nor a kernel expert by any means. but to my knowledge, the > entropy entirely comes from kb/mouse, disk, network, motherboard > timers, etc. so even if you make a note of every such event, it still > amounts to negligible cpu time or memory required. > > btw, just as a "fun fact", havege collects this entropy too. it is a > misconception that it generates any extra to the above. > > > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
