> 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 for a wide range of CPU > architectures, each of which being deployed in its own range of systems) > can solve this system issue is IMHO naive. > > Thus, kernel space vs user space makes little difference. > > This being said, the kernel developers appear to make good faith efforts > to adapt to the ever evolving digital electronics paradigms prevailing > in a few mainstream system architectures. Is this effective versus some > criteria for RNG quality? Is this good enough for you? > > It's your duty to figure out, I guess. > > Regards, > > - Thierry Moreau >
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 well that is it's job - taking single physical instances of entropy sources, post processing it and making it available to all userland and kernel consumers. However kernel writers cannot address the full system issue because they don't know what hardware they are running on. They don't know if they are in a VM. They don't know whether or not they have access to entropic datao or whether something else has access to the same data. So one of the "things you should know" is if you run a modern Linux, Solaris or Windows on specific CPUs in specific environments (like not in a VM) then it can and will serve your userland programs with cryptographically useful random numbers, at the cost of a fairly large attack surface (drivers, APIs, kernel code, timing, memory etc.) Intel came down firmly on the side of enabling the userland. One instruction puts entropic state into the register of your running userland program. Smaller attack surface, simpler, quicker, serves multiple users whether or not they are running in on bare metal or in a VM. You have to trust the VM (as you do for anything else you do in a VM). Stuff is done in hardware to make sure it serves multiple consumers, just as an OS does stuff to serve multiple consumers. A SW userland RNG is an effective method to connect entropy sources you know about on your system to algorithms that meet your needs. The recent switch to NIST requiring 192 bits or greater in key strength has precipitated a few 256 bit SW SP800-90 implementations. I know, I wrote a couple of them and I've reviewed a few others that have been written in response to the NIST change. SW RNG code is also easy to take through certification. The different is you take the system through certification, not just the code (except for CAVS). An OS kernel writer doesn't have that advantage. So my general view is that if you are tasked with enabling random numbers in your application, userland is usually a better place to do it. Maybe in a decent library used directly by your application. Maybe with some trivial inline assembler. But only if you can control the entropy source and the sharing of it. If you can use HW features (RdRand, RdSeed, other entropy sources, AES-NI, Hash instructions etc.) then your SW task is simplified, but it assumes you know what hardware you are writing for. Ditto for other platforms I'm less familiar with. The mistake I have seen, particularly in certain 'lightweight' SSL libraries is to say "It's our policy not to do the RNG thing - we trust the OS to provide entropy" and read from /dev/urandom as a result (because /dev/random blocks on many platforms). They are trusting the thing that is not in a place where it can guarantee entropy sources are available. It will work on some platforms and will certainly fail on some platforms, particularly lightweight platforms with Linux kernels on CPUs with no deliberately designed source of entropy which is where lightweight SSL libraries are used most. DJ _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
