[NCLUG] My attempts using /dev/random...

[Bob Proulx]

Chad Perrin wrote:
> Sean Reifschneider wrote:
> > That's not the question.  You were previously asserting that /dev/random
> > was just a PRNG fed by a seed.  It is not.  That is /dev/urandom.

I thought Chad was joking when he said that, since he said it in the
old joke message about the number 6 being truly randomly determined.
It is random and perfectly good.  But it is also a "one time pad".

Used random numbers are like used food.  Once used the original value
has been lost.

> > /dev/random directly exposes an entropy pool, in a cryptographically secure
> > way, to the user.  It is not a PRNG using a seed in any way that I think
> > the rest of us would agree fits the definition.
> > 
> > That's the point I think Jim is trying to make, and you are missing.
> 
> I'm not missing that.  You're just suggesting that somehow the fact
> there's essentially a random seed for every single operation makes the
> process different than using a limited pool of seeds, then repeating the
> last operation or set of operations.  All that really changes, as I
> understand it, is whether or not the process waits for more "randomness"
> before proceeding.

No.  The addition of more randomness into the entropy pool changes the
state in a random and unpredictable way.  This differentiates it from
a pseudo random number generator where the result is predictable once
the state is known.

> Both /dev/random and /dev/urandom use the "entropy pool".  The difference
> is that /dev/random uses it in a manner that provides stronger
> "randomness" by refusing to continue if it runs out of "entropy".

That is the exact point which separates /dev/random from a PRNG.  The
addition of entropy is the addition of new and unpredictable data.  At
that point it is no longer pseudo-random.

> . . . unless you know something about it that I don't.  Everything I've
> read on it gives exactly that understanding, though.

As I read things if you want to argue against /dev/random being random
then your best attack would be to attack it at the entropy sources.
If the input to it is predictable then result becomes predictable.
(After a fashion.  It would not be easy regardless.)  Is this what you
are trying to say?  That the input sources of entropy are predictable?

In the Linux kernel the /dev/random driver uses best known methods of
extracting random bits, entropy, from the external world.  It is
conservative about estimating the amount of entropy it has extracted.
If you believe you have found a way to predict these previously
unpredictable inputs then this would make for a good article and would
get you notable recognition in the field.

Bob