sparc32 & gnupg speed problems?

Enzo Michelangeli Enzo Michelangeli" <enzom@bigfoot.com
Sat, 15 Jan 2000 15:04:25 +0800


Yes, I totally agree with Bodo. rndunix spends every time an awful lot of
time (2 - 3 seconds on a Ultra 5) running various UNIX commands to gather
entropy. With EGD one can collect entropy in background, just as /dev/random
does.

Enzo

P.S. I might be triggering a religion war here, but I believe that
/dev/urandom (or EGD with the --bottomless option) should suffice to ensure
security, and at the same time would remove occasional snags when the
entropy collector finds that the pool is depleted, and stops until it
gathers new entropy. My thesis is that a pseudo-random generator (PRNG) is
normally sufficient for key generation, *if* its internal state cannot be
guessed (which normally is ensured by the use of one-way hashes). The
purpose of seeding is precisely to make the initial state unguessable. If
the future output could be predicted only by observing the previous output,
without knowing the internal state, then the PRNG would not be doing its job
right and should be fixed.
So, the "right" behaviour for a secure AND efficient EGD should be to start
initially in non-bottomless (i.e., blocking if entropy-starved) mode, and
then revert to bottomless once a sufficient initial amount of entropy has
been gathered.

----- Original Message -----
From: Bodo Moeller <bmoeller@hrzpub.tu-darmstadt.de>
To: <g10@gnupg.org>
Sent: Saturday, January 15, 2000 9:59
Subject: Re: sparc32 & gnupg speed problems?



> Chris Ruffin <c.ruffin@ieee.org>:
>
> > Hello, I'm using gnupg on both sparc32 and linux platforms. I've
> > noticed a tremendous speed difference between the two platforms, and
> > was wondering if there was something I was doing wrong. Signing an
> > e-mail message with gnupg on a sparc workstation (ultra 1) takes about
> > 20 seconds, while my trusty 486/50 MHz Linux machine signs the same
> > message (using the same key) in about a second flat. [...]
>
> This could be because collecting enough randomness takes some time.
> Did you look at the entropy-gathering daemon, EGD?
>