Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Michael Greene
The linux kernel also has a shared DMA buffer system which might be able to help with that latency, but that is a good point nonetheless. Latency could probably also be helped further by splitting that procedure into a collector and a processor/output function, to keep the overhead on DMA

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Russell Leidich
"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

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Michael Greene
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

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Ben Laurie
On 9 May 2016 at 10:01, Luca Testoni wrote: > On 06/05/2016 18:12, Kevin wrote: >> I may be way off but it seems to me that a colonel level RNG can only >> pick up entropy from boot which means hardware noise. Isn't that easy >> to beat with an acoustic attack? Maybe user

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Russell Leidich
"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

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Krisztián Pintér
d...@deadhat.com (at Saturday, May 7, 2016, 11:35:24 PM): > Well designed entropy sources > on silicon generate between 200Mbits/s and 5Gbits/s per source. I think > most vendors are getting in on the act. We have been pretty open with our > ES designs and I've seen very smart ES papers. I

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Krisztián Pintér
Russell Leidich (at Saturday, May 7, 2016, 8:47:33 PM): > Whatever its absolute value might be, the amount of entropy in the > DMA timing skew has to be higher in practice than that in interrupt > timing. The reason is that, for every interrupt, thousands or even > billions of DMA transactions

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Kevin
That was my original point. However, I now realize how much of a nightmare that would be. On 5/9/2016 5:37 AM, Luca Testoni wrote: On 06/05/2016 19:48, Russell Leidich wrote: But to answer your question, if we assume that the TRNG resides in the kernel, I see no way in which an acoustic

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Luca Testoni
On 06/05/2016 19:48, Russell Leidich wrote: > But to answer your question, if we assume that the TRNG resides in the > kernel, I see no way in which an acoustic attack could defeat it, even > if the implementation sourced its randomness exclusively from the > microphone, as too much audio

Re: [cryptography] Kernel space vs userspace RNG

2016-05-09 Thread Luca Testoni
On 06/05/2016 18:12, Kevin wrote: > I may be way off but it seems to me that a colonel level RNG can only > pick up entropy from boot which means hardware noise. Isn't that easy > to beat with an acoustic attack? Maybe user space is a bit better > because you have more entropy to be gathered.