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

[James DeWitt]

On Monday 14 April 2008 8:47:33 pm Chad Perrin wrote:
> On Mon, Apr 14, 2008 at 05:34:25PM -0600, James DeWitt wrote:
> > On Monday 14 April 2008 4:26:06 pm Chad Perrin wrote:
> > > On Mon, Apr 14, 2008 at 01:09:26AM -0600, Sean Reifschneider wrote:
> > > > >Unfortunately, the harsh truth is that both /dev/random and
> > > > > /dev/urandom are flawed.  They're PRNGs -- they do not provide
> > > > > *true* random numbers.
> > > >
> > > > /dev/random on Linux is *NOT* simply a PRNG.  Which is why it took
> > > > nearly a day to gather enough entropy for 1.6MB worth of /dev/random
> > > > output. See the comments at the top of the /dev/random driver source
> > > > for information about how it collects entropy, or it's approximation
> > > > of it.
> > >
> > > The reason it took so long involved collecting seed data.  Whether or
> > > not you consider it a PRNG really depends on whether you consider the
> > > number generating algorithm to qualify something as a PRNG, regardless
> > > of seeding behavior.
> >
> > Interesting.  Please explain the algorithm that Linux uses for
> > /dev/random
>
> overview:
>
>   http://en.wikipedia.org/wiki//dev/random#Linux
>
> In short, /dev/random and /dev/urandom use the same algorithm, except
> that when /dev/urandom "runs out of entropy" bit it just starts over on
> what it already has -- and when /dev/random runs out, it waits until it
> gets more.  What each of them uses to "generate entropy" is whatever
> activity is going on at the time on the computer -- keystrokes, I/O
> operations, et cetera.  This is generally quite more than sufficient for
> cryptographic purposes (which is about as stringent as requirements are
> going to get in our everyday lives), but in some theoretical academic
> sense a case could be made for a lot of the "entropy" generated in this
> manner being pseudo-deterministic in a lot of cases.  Unless the NSA has
> some serious blue-sky prediction stuff going on that the only the most
> paranoid of us might imagine, though, the effective difference between
> system-generated "entropy" and what you could get from quantum events is
> negligible.

That is not quite what the source says. It makes a sharper distinction between
the quality of the random numbers from /dev/random and /dev/urandom.

"
 * The two other interfaces are two character devices /dev/random and
 * /dev/urandom.  /dev/random is suitable for use when very high
 * quality randomness is desired (for example, for key generation or
 * one-time pads), as it will only return a maximum of the number of
 * bits of randomness (as estimated by the random number generator)
 * contained in the entropy pool.
 *
 * The /dev/urandom device does not have this limit, and will return
 * as many bytes as are requested.  As more and more random bytes are
 * requested without giving time for the entropy pool to recharge,
 * this will result in random numbers that are merely cryptographically
 * strong.  For many applications, however, this is acceptable.
"
Looking through the docs and code, I can't see how the system entropy
pool could be considered just random seeds.