Alternate egd socket

[Werner Koch]

On Thu, 10 Feb 2000, Dave Dykstra wrote:

> Also, EGD can eat up a lot of memory, especially if multiple people are
> running it.  At least GnuPG offers the "rndunix" alternative to EGD (on

EGD should be run as system service to replace the missing /dev/random
(okay not a real replace but in the case of GnuPG it is a replace because
/dev/random is used only as a seed to the internal PRNG).  IMO it does
not make sense to run it for each user - quite bad for system load.

> I don't understand why EGD or lots of new entropy is needed to choose
> session keys.  Nonfree-ssh and PGP got away without and I haven't heard

Well nobody complained, and it doesn't make the random numbers worser
;-).  This is an area which could be improved.  

Today, I thing that lower grade entropy seeded from the last random
buffer state should be sufficient for most tasks.  Seeding the
internal RNG with a higer quality entropy can indeed be done only for
key generation.

> of entropy and then they save what they found in a seed file, and only do

This is like /dev/random is operated - it loads it's intrnal entropy
buffer on system startup with the saved one from the last shutdown.
I guess GnuPG should do this too.  The saved entropy can't make the
random bad but helps in cases where we don't wnat to extract too many
bytes from /dev/random or EGD.

> potential problem with this if somebody were to seize a PC, because they
> could possibly be able to figure out previously selected session keys from
> that seed, but I don't know if that's possible; presumably if a one way
> hashing function is used they wouldn't be able to figure out a previous

Right, it should not be possible to get a clue of the internal RNG
state from any RNG output.  This is done by using a copy of the
RNG pool and mixing it up for each data request from the RNG.  This is
what rfc1750 recommends.

> state.  Besides, I do not care at all about the risk of somebody seizing my
> computer.  If this is the reason for not keeping the random seed file,
> perhaps there can at least be an option to keep the seed file so choosing
> of random session keys can be faster for those of us who don't worry about

IMHO, is someone is able to access the random seed file, he will also
be able to access the secret keyring ... well, and then he loads it
down starts a dictionary attack and in kost cases he will be able to
get the passphrase.  Why the trouble and messing with random numbers
to get _one_ message decoded when you are abe to get the secret key.
[Yes, I know, you all use these very long unguessable passphrases ;)]

Let's see whether I can implement it for the next release.

  Werner