sparc32 & gnupg speed problems?
em at who.net
Sat Jan 15 15:04:25 CET 2000
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
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
----- Original Message -----
From: Bodo Moeller <bmoeller at hrzpub.tu-darmstadt.de>
To: <g10 at gnupg.org>
Sent: Saturday, January 15, 2000 9:59
Subject: Re: sparc32 & gnupg speed problems?
> Chris Ruffin <c.ruffin at 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?
More information about the Gnupg-devel