[Cryptography] Plenty random for everyone

[John B]

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).
> 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, 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.

As I understand it the benefits would be that:
a) One particular app can't DOS the system (not sure about that?)
b) Craziness like "dd if=/dev/random of=/dev/sda" should work 'better'
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.*
d) Apps designers don't really need to worry about if they should be using
/dev/random or /dev/urandom
e) No more blocking on /dev/random

Some drawbacks:
a) it may somehow affect backward compatibility (?)
b) some people may insist on getting 'true' randomness and not just CS
randomness** (?)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140221/b0ad4a5d/attachment.html>