[Cryptography] Plenty random for everyone

[ianG]

On 21/02/2014 07:13 am, John B wrote:
> Hi All,
> 
> Long time lurker - first time posting. Please be nice...
> 
> I've been pondering Ted's comments here:
>> Some people have whined at me about the speed of /dev/urandom, and how
>> "wasteful" it is in CPU utilization.  In my original conception of the
>> world, something like the Open VPN server or the Kerveros KDC server
>> would periodically grab randomness from /dev/random, and then run
>> their own CSRNG in userspace.  Originally back in 1994, /dev/urandom
>> was almost an afterthought; I thought the more popular interface would
>> be /dev/random.  Which shows you how much I knew back then.  :-)
>>
>> Over time, it's been clear that people don't want to implement their
>> own CSRNG in userspace, and they would much rather use /dev/urandom
>> for everything --- session keys, random padding, even to wipe a hard
>> drive ("dd if=/dev/urandom of=/dev/hdc bs=8k").  The last is probably
>> ludicrous, but if you have a really prolific user of /dev/urandom,
>> this can be a measurable amount of CPU time (and battery consumed).


If the user is a person who typed the above command, then 'whatever'.

If however the user is an app on a mobile phone where battery is
important then I guess their battery will tell them that using urandom
for that purpose is less than friendly.  But again it seems like an
optimisation best left to user space.


>> For example, if you set up the kernel tracepoint
>> "extract_entropy_user", and then try reading e-mail using the Chrome
>> browser and gmail, you will probably be quite astounded how reads from
>> /dev/urandom you will find.
> 
> So my question is, assuming using /dev/random as a seed for a userspace
> CSPRNG is the 'right' way to go about the business of getting random
> numbers,

That's a big assumption.


> should (/could) we perform this action on the applications behalf?

> As an example, a process with PID 2 (init was already using 1 :-)) does a
> read of /dev/random. Kernel side creates a slab of mem for holding the
> state of a CSPRNG for that specific PID which is then seeded by the 'real'
> /dev/random and returns data from that instead. This state continues to be
> used as more data is requested by the app. The state will be periodically
> seeded as and when needed.
> Similarly, PID 3, 4 etc would get their own independent slab/RNG state.


So, you are assuming that all this 'equality' of purpose lies within the
PID process, and firewall should be erected between the PID/processes.
I'd say that was just another assumption taken from the pov of
convenience.  E.g., we can do that, regardless of whether it is helpful.

Two counterpoints: Some apps are spread across multiple processes.  Some
apps have high quality needs and low quality needs.  E.g., the wiping of
data /versus/ construction of high quality keys.

> As I understand it the benefits would be that:
> a) One particular app can't DOS the system (not sure about that?)


Now they all can, together or individually :)

> b) Craziness like "dd if=/dev/random of=/dev/sda" should work 'better'

I don't know how you derive that conclusion...

> c) Attacks where a malicious actor attempts to manipulate the state of the
> entropy pool by writing data to /dev/random should be mitigated as the
> attacker can only manipulate the state of PIDs they own.*

True in principle, but I personally would rather concentrate on finding
the primary weakness and fixing it.  For all processes, assuming they
are all equally important.  OK, I see the point of this if userland is
used as a sort of sandbox as it is in Android.

> d) Apps designers don't really need to worry about if they should be using
> /dev/random or /dev/urandom

This is a point that has been highlighted by FreeBSD's approach.  What I
would like to see is some empirical observations as to whether this
approach has worked better/worse over the long term.  They've been doing
it for about a decade (memory?) so we should have some sense of the
benefit here.

> e) No more blocking on /dev/random

Right, but this is also gained by just turning random to be symlink to
urandom.


> Some drawbacks:
> a) it may somehow affect backward compatibility (?)

Random numbers are inherently backward compatible :)

> b) some people may insist on getting 'true' randomness and not just CS
> randomness** (?)


Right, why?  Q for FreeBSD.  What was that insistence really about?  I'm
genuinely curious as to where we need real random numbers as opposed to
CSRNs.

> c) It requires some more memory kernel side
> d) point e, f and g where I have overlooked something obvious and in all
> likely-hood show stopping...
> 
> Regards,
> John
> 
> * I've not read *anything* that leads me to believe an attack like this is
> actually plausible - but it may help address those ongoing concerns I've
> seen on this mailing list.
> 
> ** Tongue in cheek comment. Flame at will.


Well, it is a good time to explore all this.  I would say brave effort,
but you have failed to make your case, at least for me.  This is a good
example of how hard it is to do 'better' than the platform, which
presumably has smart people working for a long time on the problem, with
lots more research and support.

Or, 'use what your platform provides' aka Rule #1 as epoused here:
http://iang.org/ssl/hard_truths_hard_random_numbers.html



iang