[onerng talk] /dev/random on Linux ...

[ianG]

Following from what I've read in the past, some comments.  This issue 
about Linux RNG has been discussed many times on the crypto group 
because there's always someone who's unhappy with Linux RNG...

On 20/12/2014 09:51 am, Jim Cheetham wrote:
> A couple of days ago I received this message from Thomas Hühn <t at 2uo.de> :-
>
>> Hi Jim,
>>
>> On http://onerng.info/random.html you claim that "This interface internally does exactly the same as /dev/random, except that when the entropy pool is close to exhaustion it will instead start to deliver data from a software device, a PRNG that has been seeded from 'good' random data.".
>>
>> That's wrong. The _only_ difference between /dev/random and /dev/urandom on Linux is that the latter doesn't care about the amount of estimated entropy in the pool(s).
>>
>> The output of /dev/random is hashed and processed in exactly the same way as the output of /dev/urandom, there is no PRNG exclusive to the latter.
>>
>> You can find more details in http://www.2uo.de/myths-about-urandom/#structure

Ah good page.  That page matches everything I've seen and goes into some 
more depth about the internals.


> I've done a fair bit of reading based on that link of his, and of
> course it opens up some more questions. I certainly used to assume
> that /dev/random's source of data was different to /dev/urandom's, and
> a quick read through random.c does indeed back up Thomas' description
> that they are indeed the same.


Yes, they should be different interfaces to the same RNG.

(One thing to note:  the meaning of *random is not consistent across 
different *nix.  For example, in FreeBSD, the urandom and random are 
exactly the same device, and they both deliver a PRNG backed by an 
internal seeding arrangment.  I am not sure what the other bsds do.)

> However, given that, I don't yet understand how re-seeding is affected
> by the entropy collector processes, I'm a little confused about
> initial seeding and how that relates to key generation, and I'm really
> stuck as to what the entropy estimate counter is trying to achieve.

One thing that I recall is that anything coming from outside should have 
entropy set to zero because there is no way to qualify it.  That would 
apply to rngd I expect?

> None of this directly affects OneRNG and its goals; it does mean that
> the default benefit to a Linux system needs more consideration, and I
> have to tighten up some of the text I've written on the website & put
> into presentations.

Right.  For my purposes, I need independent collectors.  That means 
independent from the system's RNG.  Once we cross the rubicon of caring 
about our platform supplier then that latter just becomes another 
collector for input.  So to me, using OneRNG to feed into the kernel's 
RNG doesn't change the equation, I want to read directly from both of 
them.  But that's just me.


> I'd appreciate some other people having a look at this article and
> giving me their comments :-)

It looks good!

iang