Re: [cryptography] Kernel space vs userspace RNG

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 13 May 2016 14:31:45 -0400 Kevin wrote: > The truth is, entropy is only really interesting if you have the funds > to hook up a Geiger counter to your computer. That's cheaper than you think:

Re: [cryptography] Kernel space vs userspace RNG

The truth is, entropy is only really interesting if you have the funds to hook up a Geiger counter to your computer. On 5/12/2016 11:18 PM, David Johnston wrote: On 5/9/2016 2:01 AM, Luca Testoni wrote: On 06/05/2016 18:12, Kevin wrote: I may be way off but it seems to me that a colonel

Re: [cryptography] Kernel space vs userspace RNG

>On 13/05/2016 10:43, Krisztián Pintér wrote: > >> okay, let me rephrase, because i was not very clear. what i tried to >> say is: if we assume a precision with which we can possibly measure >> the initial conditions, then there is a time interval after which the >> system is in total uncertainty.

Re: [cryptography] Kernel space vs userspace RNG

On 13/05/2016 10:43, Krisztián Pintér wrote: > okay, let me rephrase, because i was not very clear. what i tried to > say is: if we assume a precision with which we can possibly measure > the initial conditions, then there is a time interval after which the > system is in total uncertainty. this

Re: [cryptography] Kernel space vs userspace RNG

On Fri, May 13, 2016 at 10:19 AM, Luca Testoni wrote: > Not only time but initial conditions too. > The result of a chaotic system is strongly dependent on intial > conditions too. okay, let me rephrase, because i was not very clear. what i tried to say is: if we assume a

Re: [cryptography] Kernel space vs userspace RNG

On 13/05/2016 10:03, Krisztián Pintér wrote: > 2, why not chaos? we do know that it is impossible to learn every > information about a system. and if it is chaotic, our predictions > diverge from reality exponentially with time. this means that there is > an amount of time in which the inevitable

Re: [cryptography] Kernel space vs userspace RNG

Yes, here is https://www.academia.edu/22862579/Un_TRNG_basato_sulla_Teoria_del_Caos I've planned to translate it in english but for now unfortunately i've only the italian version, sorry for that. In chapter 4 there's the math explanation of double scroll and in chapter 5 there's the schema i've

Re: [cryptography] Kernel space vs userspace RNG

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

"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

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

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

"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

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

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

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

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

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.

Re: [cryptography] Kernel space vs userspace RNG

> > Russell Leidich (at Friday, May 6, 2016, 10:16:12 PM): >> 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

Re: [cryptography] Kernel space vs userspace RNG

Quite right, userspace cannot launch a DMA other than indirectly via OS calls targetting various devices. (At least, let's hope not!) 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,

Re: [cryptography] Kernel space vs userspace RNG

Russell Leidich (at Friday, May 6, 2016, 10:16:12 PM): > 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

Re: [cryptography] Kernel space vs userspace RNG

> > This was pretty much my thinking (though idk Intel thought similar). If > this is debatable, that's fine as long as my view isn't totally > batt-shit-crazy :) > I'm the RNG Tzar and I approve this message. ___ cryptography mailing list

Re: [cryptography] Kernel space vs userspace RNG

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

Re: [cryptography] Kernel space vs userspace RNG

Alright that makes sense. On 5/6/2016 1:48 PM, Russell Leidich wrote: Kevin, first of all, Krisztian says that the kernel has access to more entropy, while you say that userspace does. In a sense, you're both correct: For its part, the kernel has access to a wider array of devices, and it's

Re: [cryptography] Kernel space vs userspace RNG

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.

Re: [cryptography] Kernel space vs userspace RNG

Kevin, first of all, Krisztian says that the kernel has access to more entropy, while you say that userspace does. In a sense, you're both correct: For its part, the kernel has access to a wider array of devices, and it's in a better position to ascertain the extent to which timing entropy is

Re: [cryptography] Kernel space vs userspace RNG

On Thu, May 5, 2016 at 11:40 AM, shawn wilson wrote: > Just reflecting on the Linux RNG thread a bit ago, is there any technical > reason to have RNG in kernel space? i think it is worthwhile to separate the topic to entropy collection and prng. prng is the easier part. the

Re: [cryptography] Kernel space vs userspace RNG

On Thu, May 5, 2016 at 2:40 AM, shawn wilson wrote: > I wonder what the gain is for putting RNGs in the kernel. > A naive userspace RNG will duplicate its internal state when you fork, which can be catastrophic in a cryptographic context. That's a problem that can be fixed by

Re: [cryptography] Kernel space vs userspace RNG

All else being equal, I would prefer to have my TRNG in the kernel, for the aforementioned reasons of memory access security. But in the real world, this distinction is minor. More significantly, kernel TRNGs differ from userspace ones in their use of hardware sources of randomness, such as

Re: [cryptography] Kernel space vs userspace RNG

On May 5, 2016 2:22 PM, wrote: > > I think this sums it up well. Today you are thrown into having to know > what to do specifically because it's a system level problem (matching > entropy sources to extractors to PRNGs to consuming functions). > > The OS kernel does a thing

Re: [cryptography] Kernel space vs userspace RNG

> On 05/05/16 09:40 AM, shawn wilson wrote: >> Just reflecting on the Linux RNG thread a bit ago, is there any >> technical reason to have RNG in kernel space? > > The procurement of an RNG source for crypto is always a *system* design > issue. > > The expectation that a kernel offering (intended

Re: [cryptography] Kernel space vs userspace RNG

I personally feel that this is overkill. However, it is always a good idea to cover all of your bases so I would never say that it's a bad idea. One can never be to secure! On 5/5/2016 5:40 AM, shawn wilson wrote: Just reflecting on the Linux RNG thread a bit ago, is there any technical

Re: [cryptography] Kernel space vs userspace RNG

One technical reason could be that at least some of the entropy sources are also in the kernel, so it makes some sense to put the RNG there, too. It'd probably be more implementation effort to be able use the same entropy sources in a userspace tool. Another justification could be that it is