Alternate egd socket

[Dave Dykstra]

On Thu, Feb 10, 2000 at 02:23:54PM +0100, Alexander Zimmermann wrote:
> Hello,
> 
> I'd like to get the entropy from egd within gpg from an alternate socket
> path (f.e. /tmp/entropy) on my solaris system, so it's not necessary
> that every user starts it's on egd.
> Of course I can link $HOME/.gnupg/entropy to /tmp/entropy and this would
> work, but it's very annoying to new users of gnupg to first create this
> link before starting gnupg.
> I've patched the sources to look for an environment variable EGDSOCKET
> and connect to it, if it exists. This works, but
> 
> 1) is this a good approach?
> 2) is there a better alternative?
> 3) is it safe to only have one egd that all users can use?

You don't explicitly say, but because of your choice of /tmp/entropy as
the path I'm guessing that you're planning on having the first user that
runs egd create the socket, as opposed to the superuser.  I believe that is
unsafe, because if a malicious user got in there first they could have
their own modified EGD and control what "entropy" the rest of the users
get.  If you're going to have the EGD run as root, it would be better to
choose a root-only directory, like /etc/entropy.

I have been strenously arguing against the need for EGD on the OpenSSH
list, because it is extremely impractical in my case where I widely
distribute the binaries in my company using an unprivileged user id, where
I have no option of installing things as root on all the end machines.
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
machines that don't have /dev/random), but that makes --encrypt very
slow as it collects lots of entropy before choosing a random session key.

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
people criticizing them for that.  For key generation they both gather lots
of entropy and then they save what they found in a seed file, and only do
lightweight, fast entropy collection for choosing session keys.   I see a
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
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
seizures.  (In the case of OpenSSH, seizure is totally a non-risk because
previously generated session keys should be of no value once a machine is
seized).

- Dave Dykstra