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

Chad Perrin perrin at apotheon.com
Wed Apr 23 18:27:52 MDT 2008


On Sat, Apr 19, 2008 at 11:56:38AM -0600, Bob Proulx wrote:
> Chad Perrin wrote:
> > Sean Reifschneider wrote:
> > > /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.

If you know the state, you can predict future state (theoretically).
That's not changed by using a randomly generated number to set the state
that is used to calculate the next number.  That's sorta my point.


> 
> > 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.

Effectively true, assuming our beliefs about the operation of the
algorithm used to generate a new number are true.  It may eventually turn
out that there's some flaw in the algorithm -- though that's just getting
into pedantry, and I probably shouldn't have brought it up.  I just can't
help myself.


> 
> > . . . 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?

I'm not saying it's necessarily "unrandom" in effect.  I'm just saying
that it uses the same process for generating a number as /dev/urandom,
with the key difference being the input it accepts -- not what it does
with that input to produce output.  In other words, the randomness isn't
really in /dev/random itself, but in what you give it.  All /dev/random
does for you is turn that into part of a range that you expect.

. . . unless there's something else going on there that I've missed, as I
said.


> 
> 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.

That's not where I'm going with this.  I'm not even saying that
/dev/random is in some way flawed at all.  I'm just saying that the only
difference between /dev/random and /dev/urandom, as I understand it, is
what input it accepts.  One might say it's a pseudorandom number
generator that works with true random seeds, changing the seed with every
operation, in other words.  Saying so, though, depends on one's
definition of "number generator".  Does input acceptance criteria impact
whether a "number generator" is random or pseudorandom?  That depends on
whether the definition of "number generator" that you use starts before
or after the point where input is accepted.

I'm splitting hairs, but sometimes it's fun to do so.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade. 
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.nclug.org/pipermail/nclug/attachments/20080423/e466c882/attachment.pgp>


More information about the NCLUG mailing list