Non-interoperability with PGP: case solved

Enzo Michelangeli em at
Sat Mar 11 12:58:55 CET 2000

----- Original Message -----
From: "Werner Koch" <wk at>
To: <gnupg-users at>; <gnupg-devel at>
Sent: Wednesday, March 08, 2000 19:43
Subject: Re: Oh, no: inter-version 3DES incompatibility strikes again :-(

> On Wed, 8 Mar 2000, Enzo Michelangeli wrote:
> > The problem occurs trying to decrypt with PGP data encrypted with GnuPG,
> > the other way round. GnuPG 1.0.1 creates this sort of packets:
> >
> > :symkey enc packet: version 4, cipher 2, s2k 3, hash 3
> > ...whereas PGP 6.5.1 creates these others (with another plaintext):
> > :symkey enc packet: version 4, cipher 2, s2k 3, hash 2
> GnuPG uses RIPEMD-160 and PGP uses SHA-1 as the hash algorith used to
> make a key out of the passphrase.  I can't see that any of these
> implementaions violate RFC2440 here.  I know that SHA-1 is a required
> alogorithms and RIPE is optional but because there is no way to
> negotiate this parameters (like the preferences we use with public
> keys) both encodings are valid.

No, the hash was a red herring. I have found how to make GnuPG 1.0.1 and
0.97 interoperate with PGP: specify "--compress-algo 1". By default, gnupg
uses 2, and PGP 6.5.1 chokes on it.

Packets produced by GnuPG 1.0.0 are still not decoded by PGP, who detects a
"bad key".


More information about the Gnupg-devel mailing list