On May 5, 2016 2:22 PM, <d...@deadhat.com> 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 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. >
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 :)
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
