[cryptography] Kernel space vs userspace RNG
pkejjy at gmail.com
Fri May 6 16:16:12 EDT 2016
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 <pinterkr at gmail.com> 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
> 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
> cryptography at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography