<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi All,<br><br>Long time lurker - first time posting. Please be nice...<br><br></div>I've been pondering Ted's comments here:<br>> Some people have whined at me about the speed of /dev/urandom, and how<br>
> "wasteful" it is in CPU utilization.  In my original conception of the<br>> world, something like the Open VPN server or the Kerveros KDC server<br>> would periodically grab randomness from /dev/random, and then run<br>
> their own CSRNG in userspace.  Originally back in 1994, /dev/urandom<br>> was almost an afterthought; I thought the more popular interface would<br>> be /dev/random.  Which shows you how much I knew back then.  :-)<br>
> <br>> Over time, it's been clear that people don't want to implement their<br>> own CSRNG in userspace, and they would much rather use /dev/urandom<br>> for everything --- session keys, random padding, even to wipe a hard<br>
> drive ("dd if=/dev/urandom of=/dev/hdc bs=8k").  The last is probably<br>> ludicrous, but if you have a really prolific user of /dev/urandom,<br>> this can be a measurable amount of CPU time (and battery consumed).<br>
> For example, if you set up the kernel tracepoint<br>> "extract_entropy_user", and then try reading e-mail using the Chrome<br>> browser and gmail, you will probably be quite astounded how reads from<br>
> /dev/urandom you will find.<br><br></div>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?<br>
<br></div>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.<br>
</div>Similarly, PID 3, 4 etc would get their own independent slab/RNG state.<br><br></div>As I understand it the benefits would be that:<br></div></div>a) One particular app can't DOS the system (not sure about that?)<br>
</div>b) Craziness like "dd if=/dev/random of=/dev/sda" should work 'better'<br>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.*<br>
</div>d) Apps designers don't really need to worry about if they should be using /dev/random or /dev/urandom<br></div>e) No more blocking on /dev/random<br><div><div><br></div><div>Some drawbacks:<br>a) it may somehow affect backward compatibility (?)<br>
</div><div>b) some people may insist on getting 'true' randomness and not just CS randomness** (?)<br></div><div>c) It requires some more memory kernel side<br>d) point e, f and g where I have overlooked something obvious and in all likely-hood show stopping...<br>
<br></div><div>Regards,<br>John<br></div><div><br>* 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.<br><br></div><div>** Tongue in cheek comment. Flame at will.<br></div></div></div>