Mailing List Archive

Chris Ruffin writes:
>
> 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. I compiled gnupg
> for sparc myself using:
>
> ./configure --disable-nls --disable-dev-random --prefix=$HOME
>
> The linux gnupg was installed from the standard debian package.
>
> Is anyone aware of any speed related issues with sparc32?

You are using the standard Unix random gatherer? The section near the top of
gpg's install file states:

...
--enable-static-rnd=<name> Force the use of the random byte gathering
module <name>. Default is either to use /dev/random
or the standard Unix module. Value for name:
...
unix - Use the standard Unix module which does not
have a very good performance.
...

You should go and try egd, that what I use here on Solaris.

On Thu, Jan 13, 2000 at 09:15:35AM -0600, Chris Ruffin wrote:
>
> 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. I compiled gnupg
> for sparc myself using:
>
> ./configure --disable-nls --disable-dev-random --prefix=$HOME

GnuPG doesn't know how to distinguish between the various architectures. So
it choose v7 by default.
Edit mpi/config.links and rename to "sparc*-*-*)" the sparc case
corresponding to your architecture level.
For example, on my SS10 (supersparc), I patched mpi/config.links this way :

Index: config.links
===================================================================
RCS file: /home/koch/cvs/gnupg/mpi/config.links,v
retrieving revision 1.22.2.2
diff -u -r1.22.2.2 config.links
--- config.links 1999/12/16 09:10:39 1.22.2.2
+++ config.links 2000/01/13 20:35:27
@@ -87,14 +87,9 @@
echo '/* configured for sparc8 */' >>./mpi/asm-syntax.h
path="sparc32v8 sparc32"
;;
- supersparc*-*-*)
+ sparc*-*-*)
echo '/* configured for supersparc */' >>./mpi/asm-syntax.h
path="supersparc sparc32v8 sparc32"
- mpi_extra_modules="udiv"
- ;;
- sparc*-*-*)
- echo '/* configured for sparc */' >>./mpi/asm-syntax.h
- path="sparc32"
mpi_extra_modules="udiv"
;;
mips[34]*-*-* | mips*-*-irix6*)

The problem was that gpg was not using EGD, but lpstat, ps, and
netstat to generate random numbers. After properly installing EGD,
the program runs like a champ.

Thanks,

Chris Ruffin
--
Chris Ruffin <c.ruffin@ieee.org>
http://www.ece.msstate.edu/~ruff/

On Thu, Jan 13, 2000 at 09:42:45PM +0100, Remi Guyomarch wrote:
> On Thu, Jan 13, 2000 at 09:15:35AM -0600, Chris Ruffin wrote:
> >
> > 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. I compiled gnupg
> > for sparc myself using:
> >
> > ./configure --disable-nls --disable-dev-random --prefix=$HOME
>
> GnuPG doesn't know how to distinguish between the various architectures. So
> it choose v7 by default.
> Edit mpi/config.links and rename to "sparc*-*-*)" the sparc case
> corresponding to your architecture level.
> For example, on my SS10 (supersparc), I patched mpi/config.links this way :
>
> Index: config.links
> ===================================================================
> RCS file: /home/koch/cvs/gnupg/mpi/config.links,v
> retrieving revision 1.22.2.2
> diff -u -r1.22.2.2 config.links
> --- config.links 1999/12/16 09:10:39 1.22.2.2
> +++ config.links 2000/01/13 20:35:27
> @@ -87,14 +87,9 @@
> echo '/* configured for sparc8 */' >>./mpi/asm-syntax.h
> path="sparc32v8 sparc32"
> ;;
> - supersparc*-*-*)
> + sparc*-*-*)
> echo '/* configured for supersparc */' >>./mpi/asm-syntax.h
> path="supersparc sparc32v8 sparc32"
> - mpi_extra_modules="udiv"
> - ;;
> - sparc*-*-*)
> - echo '/* configured for sparc */' >>./mpi/asm-syntax.h
> - path="sparc32"
> mpi_extra_modules="udiv"
> ;;
> mips[34]*-*-* | mips*-*-irix6*)

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?
>