[onerng talk] What is the entropy generation rate of the OneRNG?

ianG iang at iang.org
Wed Aug 19 23:24:14 BST 2015

On 19/08/2015 23:12 pm, Paul Campbell wrote:
> On Thu, 20 Aug 2015 09:56:48 jld wrote:
>> How many bits of entropy are generated per second?  And does that translate
>> to the same number of bits being fed to /dev/random or is it a different
>> measure?
> at the moment at the default setting we're making ~350k bits/sec of data with
> ~7.8 bits/byte of it actually being entropy - so ~340k bits/second

Overkill by about 3-4 orders of magnitude :)

> It's roughly the same amount as is being fed to /dev/[u]random - depending on
> the version of rngd you are using (if you're using the version that allows us
> to derate our data according to what we've measured you'll see 340k, if you
> have the older one it will register as 350k ... these differences are in the
> noise (pun not intended))
> Whether you can actually get that data rate back out of /dev/[u]random
> probably depends on your CPU speed - I think the small (2k) kernel entropy
> pool makes it hard to stream data into it fast (all the flow control overhead
> tends to build up resulting in lots of context switches).
> If you don't pull data from OneRNG at speed the data in its internal pool
> accumulates (it gets better, that 7.8bits/byte gets closer to 8)

The RNG should be feeding the "entropy" in as a seed into the PRNG, so 
there should be no limit to the output other than as you say context 
switching and PRNG machinations.

*BSD works that way, I think Linux is a bit more complicated, it's still 
working on the old school way of trying to measure entropy and feed out 
some similar claim of entropy, before switching to PRNG.

Part of the problem was that in the 1990s we believed it was all about 
entropy, so bits per second was a limiting factor, as was bits of 
entropy per bit.

But since then we're shifted philosophy somewhat and now we just want a 
good PRNG and a decent seed, which is about a block's worth - 128 bits 
is fine, 512 is as big as it gets.


More information about the Discuss mailing list