How secure is GnuPG

David Shaw
Tue Jul 23 22:38:01 2002

On Tue, Jul 23, 2002 at 03:30:23PM -0400, Daniel Carrera wrote:
> Thanks for the help.  I have a few more questions.
> > In any event, it is perfectly reasonable to make 2048 bit (or larger)
> > RSA keys if you prefer.
> Is there any drawback to using a 2048 bit key?  I know that it'll take
> longer to make the key the first time, but I don't care.  That's a
> one-time thing.
> I figure that there must be some sort of tradeoff other than the original
> key generation.  Otherwise everyone would be using a 4096 bit key.

Many people made their keys before it was so easy to make large keys.

RSA signatures get larger in proportion to the size of the key.  If
you are going to sign emails and such, be warned that a really big
signing key is going to mean one huge signature at the bottom.  DSA
signatures are very small.

Performance-wise, RSA encrypting is much faster than ElGamal, and
ElGamal is a little bit faster than RSA for decrypting.  RSA signing
is much slower than DSA, and RSA sig verification is much, much
faster.  Frankly, unless you are using a palm pilot or similar, the
speed issues don't really make that much of a difference on modern
computers.  Remember that the bulk of the encryption work is done with
the symmetric cipher (3DES, AES, IDEA, etc) and only the session key
is encrypted with RSA or ElGamal.

One of the very nice things about the OpenPGP standard is that it
allows you to use different subkeys for different actions, and they
are all neatly bound together into your one "key".

But seriously - forget all that.  The real question to ask yourself is
*what do you want to do?*  The overwhelming majority of the time,
people end up with a DSA signing key (1024, the maximum) and an
ElGamal encryption key (2048-4096).  That is a good all-round safe
choice for many uses (email being the most common example).

> > It means you need to upgrade :)  GnuPG 1.0.7 includes RSA key generation.
> Is it actually important to upgrade?
> Is it difficult to upgrade?  I mean, will my current public and private
> key rings still work?  Will they have to be "translated" to RSA?

It is very easy to upgrade, and all your keyrings will still work.
There is no such thing as translation to RSA.  GnuPG 1.0.6 can use RSA
as well - what was added was the ability to generate new RSA keys.  If
you have an existing key it should work fine.

Downgrading from 1.0.7 to 1.0.6 can be a little sticky, so if you want
to go back and forth, make a backup of your keyrings.

> > > Am I safe with my 1024 bit ElGamal key?
> >
> > Depends who your attacker is.  Unless you're concerned about a large
> > government, then probably it is.
> Well, if there is no loss, I can just be a little paranoid and go for an
> unbreakable key.
> I kind of like the idea of having a key that is beyond human technology to
> break.  Would a 2048 bit key be beyond our technology to factor?

Do you mean ElGamal or RSA here?  Either way, it's hard to say what is
"beyond our technology".  Certainly, given today's technology, it is
computationally infeasible to brute force a 2048-bit RSA or ElGamal
key in any realistic time frame.

> Also, how complex should my passphrase be?
> I chose my passphrase so that guessing it would be roughly equal to
> guessing a 128-bit key.  I figure that anymore would be overkill because
> it'd be easier to crack the 128-bit key, and any less would compromise the
> security of the 128-bit key.
> Am I right?

Yes, but it's not really realistic.  Your passphrase would be over 100
characters of gibberish, and nearly impossible to remember.  Instead,
take a look at for a much easier to remember
scheme that gives you between 60-90 (approximately) bits.

While it is generally true that the passphrase is usually the weakest
part in PGP, remember that the passphrase is just to protect the
secret key.  To start brute forcing your passphrase, an attacker has
to have already stolen your secret key.


   David Shaw  |  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson