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

Jean-Luc Duprat jld at acm.org
Fri Aug 21 00:39:18 BST 2015

Thanks this is exactly what I was looking for.


On Wed, Aug 19, 2015 at 4:04 PM, Paul Campbell <paul at taniwha.com> wrote:

> On Wed, 19 Aug 2015 23:24:14 ianG wrote:
> > 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.
> Linux essentially provides both services:
> /dev/random is a flow controlled PRND that produces data at the same rate
> that
> new entropy is mixed into it's pool, it stops when it's entropy count is 0
> /dev/urandom works exactly the same way except it doesn't stop the PRNG
> when
> entropy hits 0 - most code should use /dev/urandom
> ------------------------------------------------------------------------
> The way I see the problem is that the PRNG has some hidden state that an
> external attacker is trying to guess (to predict future, or maybe past
> values)
> every time we extract a random number from it and expose it to the world
> (TCP
> sequence numbers etc) we give away a tiny amount of information about its
> internal state, if we don't continually mix in some entropy long term an
> attacker can accumulate information - we don't have to stir in more entropy
> for every bit we take out to be functional but regular applications makes
> guessing the internal state continually hard
>         Paul
> ――
> View topic http://lists.onerng.info/r/topic/1UB2uzBUbfLZzWtBs3fMBX
> Leave group mailto:onerng-talk at lists.onerng.info?Subject=Unsubscribe
> Start groups https://OnlineGroups.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20150820/eb49e4c3/attachment.html>

More information about the Discuss mailing list