[cryptography] Kernel space vs userspace RNG

shawn wilson ag4ve.us at gmail.com
Thu May 5 19:55:09 EDT 2016

On May 5, 2016 2:22 PM, <dj at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160505/6731bf47/attachment.html>

More information about the cryptography mailing list