"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 [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
