[onerng talk] Redirect output to urandom and link random to urandom

[Paul Campbell]

On Friday, 27 May 2016 2:29:05 AM NZST alexandre wrote:
> Hi
> 
> I don't fully understand all the deep internals from urandom vs random fight
> 
> However as most programs use urandom  (firefox for tls , xca  for
> certificate, ... ) and onerng is an uninterrupted source of good entropy
> would it be a good practise to redirect onerng source to /dev/urandom with
> 'rngd -o /dev/urandom $RNGD_FLAGS' and then launch a second rngd to link
> urandom to random like this : rngd -r /dev/urandom -o /dev/random. ? 

/dev/urandom and /dev/random share a single entropy pool in the kernel - 
writing to one essentially writes to both, however the rate that entropy is 
removed from this pool is limited

If you look in the kernel source the ioctl() that /dev/random and /dev/urandom 
provides for rngd to use changes the same data structure (the common inpuit 
pool) - in effect "rngd -o /dev/random ..." and "rngd -o /dev/urandom ..." are 
identical - reading from one and writing to the other would mean you are 
effectively recycling entropy which would be wrong.

(note rngd does not do simple writes to /dev/random, it uses an ioctl() call 
that allows it to specify how much entropy it adds on each write - that way we 
can tell it that how much entropy each onerngd bit is worth when it's added to 
the pool)

One thing I've discovered recently is that you can speed up the reseeding of /
dev/urandom using:

	echo 0 >/proc/sys/kernel/random/urandom_min_reseed_secs

This has a downside in that it causes a onerng to blink once a second which 
somewhat mimics the way it reports internal errors.

I'd like to include this in the next software release, but I'm worried I'll 
get lots of error reports - probably I'll set it to 3 seconds but set it up so 
you can make it run faster if you like. Feel free to try it, but understand 
that a regularly flashing light on a OneRNG may no longer mean what you think 
(please turn it off if you think you have a problem).

(this parameter is ~3 years old, older kernels do not support it)

	Paul