RE: Re: Still wondering about random numbers...

I'm almost dead certain (although I've been too lazy to actually look,)
that
network activity also fills the entropy pool (on Linux boxen).  I
conjecture
this partly based on my headless "home services" box which acts as
firewall,
web server, game server, pg server, blah, blah, and blah on my LAN.  It
has
never wanted for entropy, and has actually never blocked on reads to
/dev/random
for any (human) appreciable lengths of time.  It drinks from the entropy
pool
for key generation and suchlike frequently and deeply.

This may require netfilter.

  -- Matt

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Allan
Engelhardt
Sent: Wednesday, August 08, 2001 6:23 AM
To: Doug McNaught
Cc: Bruno Wolff III; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Re: Still wondering about random numbers...


Doug McNaught wrote:

> Allan Engelhardt <allane@cybaea.com> writes:
>
> > On other motherboards, reading from /dev/random can stall
> > indefinitely.  This is not a Good Thing.  /dev/urandom is fine, but
> > not rally better than rand(3) or random(3).
>
> Wrong; it's still a lot better, especially if you have a reasonable
> amount of entropy coming in--/dev/urandom uses the same entropy pool
> as /dev/random and generates its data using a cryptographically secure

> hash function.  This is still a lot better (for crypto purposes) than
> the simple LCGs used in the standard C library functions.

Absolutely!  I had minor brain damage when I wrote the paragraph.  What
I meant was:

"/dev/urandom is not really better than rand(3) or random(3) *in this
situation* [i.e. when reads from /dev/random stalls and there is no
system entropy]"

You don't get a lot of entropy from the standard /dev/random drivers on
a system without users (pressing a key gives 10 bytes of entropy, moving
the mouse ~8), but you do get a some so it is better.

As you said.

Allan.


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org