[cryptography] Kernel space vs userspace RNG

Michael Greene mgreene at securityinnovation.com
Mon May 9 17:13:30 EDT 2016


Interrupts don't need to be polled in a loop in the kernel, though. As long as the interrupt handler being used to collect the data is quick enough, it wouldn't necessarily need to be resource intensive. There are only going to be 15 or 24 interrupt lines on most x86 systems, anyway. All else being equal, such an interrupt handler in the kernel would actually probably hog less CPU cycles than it would in userspace just because it doesn't need to poll at all for that information. 


On May 9, 2016 11:21:18 AM PDT, Russell Leidich <pkejjy at gmail.com> wrote:
>"how do you plan to get notice of them? the very point of DMA is that
>it
>goes on in the background, and then you get a notification."
>
>Generically speaking, you can't get any such notice due to insufficient
>privilege. The best a userspace TRNG can do is to filter out periodic
>and
>polynomial patterns in the timedelta stream, then hope that the residue
>is
>sufficiently mixed with actual physical entropy, to be secure. But it's
>possible that all that purported entropy is really just the aperiodic
>residue of other deterministic processes running on the machine. So its
>security depends upon the difficulty of (1) isolating cases in which no
>physical entropy affects the output (e.g. cold boot at deterministic
>core
>frequency before bus intitialization, which no sane security engineer
>would
>allow) or (2) inserting enough taps into the machine that despite the
>presence of physical entropy, the output can still be predicted. No
>userspace TRNG can have a rigorous proof of security, for these
>reasons.
>They are an economic compromise, essentially.
>
>"this is not the question at all. i don't doubt that userspace can see
>some
>entropy. my point was that the kernel sees everything, while userspace
>sees
>less. it is not refuted by showing examples of entropy userspace can
>collect."
>
>If you mean that the kernel can see randomness which it actually knows
>to
>be entropy, whereas the userspace can only see randomness which may be
>entropy or pseudorandomness, I agree. My point was just that collecting
>most of the physical entropy requires a tight loop. To the extent that
>kernels are willing to sit around for a while doing so, then they can
>gather unlimited amounts of entropy, given a reasonable model of DMA
>clock
>skew behavior. However, in practice, kernels hate latency, so userspace
>can
>much better afford to sit around gathering randomness, at the cost of
>not
>knowing how much of that is due to physical entropy.
>
>"please note that i also pointed out a danger: all the entropy visible
>to
>userspace might be easier to steal, because there is a chance that
>other
>programs can gather the exact same entropy (hence my example of the
>sound
>card noise)."
>
>Your sound card noise example makes sense because a single server (the
>audio driver) is broadcasting to multiple clients (parallel userspace
>TRNGs). Fortunately, timedeltas don't work like that. For example, with
>Intel Hyperthreading cores, both virtual cores compete for access to
>the
>ALUs, so they will never show the same timedelta stream for anywhere
>near
>the thousands of cycles required to produce a random number, especially
>after periodicity subtraction. I would actually expect more raw
>timedelta
>stream similarity between successive single-threaded runs, than from a
>pair
>of simultaneous runs, on account of this competition. If we're talking
>about physically separate CPUs, it only gets more complicated.
>
>By the way, I would expect to be able to detect the arrival of an IRQ
>by
>monitoring the timedelta stream in userspace, especially on more idle
>machines. This is one way in which _kernel_ entropy could be stealable.
>Intel provided a means to make RDTSC(P) illegal in userspace (via
>CR4?).
>This should be implemented, and the timestamp counter virtualized to
>hide
>kernel events, but I don't know of any OS which does that.
>
>"to some extent, havege might alleviate this, because there is no
>direct
>way to observe the parameters it collects. but this is highly
>speculative,
>as the true source of havege random is not the CPU, but the same irqs
>and
>other hw events. the CPU just acts as a hard to observe prng. so
>actually
>i'm not a fan. without looking into it deeper, i believe this is also
>true
>for enranda."
>
>You are correct. The only guarantee that I can make about Enranda, in
>the
>absence of physical entropy, is that it's a hard-to-observe PRNG with a
>state space of O(1M) bits which ignores most periodic timedelta
>sequences.
>Without a security violation of the OS, however, I think it's
>impossible to
>steal enough timedeltas across a process boundary to predict its output
>to
>any useful extent. Cache miss and timing attacks are useless, as is a
>parallel instance of Enranda. If anyone can prove otherwise, it would
>make
>a very interesting read.
>
>The ideal physical random number generator, I think, would be an analog
>computer of macroscopic size, like something soldered together inside a
>clear case. That's the only way we could verify its functionality. I
>would
>never buy something labelled "random number generator" that comes in a
>black box containing 10 nanometer features or whatever. Who knows how
>that
>would actually work under the hood.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>cryptography mailing list
>cryptography at randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography

-- 
Michael Greene
Software Engineer 
mgreene at securityinnovation.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160509/f5d70bc8/attachment.html>


More information about the cryptography mailing list