PGP & GPG compatibility

[David Shaw]

On Mon, Jan 21, 2002 at 11:03:26PM -0600, Keith Ray wrote:

> In fact, the most common reason cited for staying with PGP 2 is for
> compatibility reasons.  However, GnuPG has no way of knowing what
> version a particular key corresponds to.  Recently, various GnuPG
> "front-ends" have begun implementing multiple configurations to help
> solve this issue, but the user has to manually select which
> configuration to use with a particular recipient.  Trying to encrypt
> to multiple recipients is an exercise in futility.

Multiple receipients where some are PGP2 [1] users and some are
OpenPGP-ish (GnuPG/PGP6/PGP7) users are simply impossible to support
in all but a very small (and rare) set of circumstances.  This is not
a flaw in GnuPG or PGP - it's in the nature of the two different
standards that govern PGP2 and OpenPGP, and how the original PGP2 was
implemented.

This is somewhat long, so feel free to skip to the conclusion: It is
not completely true that GnuPG has no way of knowing what version a
particular key corresponds to: OpenPGP keys contain a list of the
ciphers (as well as hashes and other details) that key is willing to
accept.  This doesn't give the name/version of the implementation the
user is using, but it does show its capabilities.

With ciphers, if 3DES isn't on the list, it is implicitly tacked on at
the end.  This lets implementations resolve any problems that can
happen if two different keys from two different implementations
support two different sets of ciphers.  If all else fails, 3DES is
always there.  IDEA may be on this list, but this is not required in
OpenPGP.  There is a special exception to the "tack 3DES on at the
end" rule for PGP2-style keys.  In this case, the implementation is
allowed to pretend that there is a cipher list consisting of only
IDEA.

See where this leaves us: OpenPGP uses 3DES as the one cipher that
every implementation must support, and is not required to support
IDEA.  PGP2 uses IDEA as the one and only cipher, period.  We're
heading for trouble.

So, in the case when a user encrypts to a PGP2-style and OpenPGP-style
key that does not have a preference listing for IDEA at the same
time... what is the right thing to do?  There is no cipher that both
keys are willing to accept.  If the implementation follows the PGP2
key fake "preference", it violates the OpenPGP spec (and may not be
decryptable to boot).  If the implementation follows the OpenPGP key
preference, it might be sending a message that the PGP2 key cannot
decrypt.  The only hope is that the PGP2 key could be being used in a
OpenPGP implementation, which by definition could handle a 3DES
message.  A reasonable thing to do here is to figure that a "might
work" is better than a "violates the spec and probably won't work
anyway", use 3DES, warn the user, and hope.

Now that I've said all that, ignore it: it's true, but it doesn't
matter in the real world.  This is because PGP2 is extraordinarily
sensitive to *anything* it doesn't understand in a message.  Even if
you happen to be encrypting to an OpenPGP key that accepts IDEA along
with your PGP2 key, you're likely in trouble unless the OpenPGP key is
RSA and <=2048 bits (which there are nearly none of, as most are
DSA/ElGamal and most programs couldn't even generate OpenPGP RSA keys
until fairly recently).  On top of that you have a handful of fiddly
differences in how packets are constructed, and the bottom line is
that your comment earlier is absolutely right - trying to encrypt to
multiple recipients (unless they're *all* PGP2 people) is an exercise
in futility.

So basically, this is a long winded way of saying you can be PGP2
compatible, and you can be OpenPGP compatible, but you can't really do
them both at the same time.  One answer, and how I implemented --pgp2
in GnuPG, is to try and force the issue: just do *everything* the PGP2
way and keep an eye on what the user is requesting.  If they request
something that just won't work with PGP2, say so and say why, so at
least the user knows what is going on and won't be surprised when they
try to use PGP2 to process the message.  Since GnuPG/PGP6/PGP7 all
understand PGP2 messages, this does give you one configuration for all
messages, but of course, you don't get to use most of the new OpenPGP
features.

Probably more detail than most people care about, but the point I'm
eventually getting to here is that this is not something that can be
trivially fixed with code.  The real problem here is that PGP2 and the
OpenPGP-ish programs (GnuPG/PGP6/PGP7) follow two different (albeit
related) standards, and PGP2 is almost completely unforgiving with
anything that is not exactly to its standard.  Interoperating between
GnuPG and PGP6 or 7 even with varying levels of conformance to the
OpenPGP standard is a walk in the park compared to interoperating with
a different standard altogether.

The answer?  Upgrade from PGP2 to something more OpenPGP-ish.  You get
to keep your old keys, you gain lots of interesting OpenPGP features,
and you make life easier for all the people who communicate with you.

David

[1] "PGP2" here means "MIT PGP 2.6.2".  There are other variations on
    PGP2, including the high-octane PGP 2.6.3ia-multi
    (http://disastry.dhs.org/pgp/263multi.htm) which supports lots of
    modern ciphers and other features.  Unfortunately, there is no way
    to tell just from looking at the key that a receipient is using
    this version, so the sender usually must assume otherwise.

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "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



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com