[patch] PGP 2.x compatibility

Werner Koch wk at isil.d.shuttle.de
Tue Mar 16 20:03:01 CET 1999

Remi Guyomarch <rguyom at mail.dotcom.fr> writes:

> With this (a bit large) patch, encrypting to only RSA v3 pubkeys,
> signing with RSA v3 seckeys or symmetric encrypting with --rfc1991
> selects a slightly different output format which is compatible with
> PGP 2.6.3i and PGP 5.0i.

Thanks for all the work you did but I'm sorry to say, that I can't
apply it:

  1. For such a long patch the FSF needs a disclaimer - If you can do
     so - fine.  And I'd really like to see more people with a FSF
     "clearance" - I know thta this is sometimes problematic if your
     employer wnat sign his part.

  2. I don't like the idea of temporary files.  It  makes the program 
     more complicated and one goal of GnuPG is to avoid such things.

  3. I will (and can't) not add any support for the patented algorithm
     IDEA  - there is no need for it.

  4. Most of the patches are intended for better PGP 2
     interoperability.  If you need this - use PGP 2 or ask Michael to 
     add a fallback mechanism to pgpgpg.  PGP 2 should be replaced by
     more modern programs and therefore I don't think that it is a
     good idea to do too much work to help old PGP 2 users.

  5. There is a standard called OpenPGP which is defined in RFC 2440
     and if PGP >= 5 has problems with this standard it is simply
     NAIs duty to fix this.  We can't worlk around all the bugs in
     PGP5.  I'm willing to add what's really needed (ala
     --force-v3-sigs) but not everything.  It would make the standard 

> DSA/ElGamal key pair are probably still using PGP 2.x, for example to
> use the type 1 remailer network (which is still heavly based on PGP
> 2.x format).

So they have to stick with PGP 2 or change the remailers.

> PGP 2.6.3i and PGP 5.0i needs an exact byte count in nearly all

This is correct for pgp 2.  PGP 5.0 is quite old and has a couple of
bugs.  We are not going to work around them.

> packets (encrypted data packet, compressed packet, litteral data
> packet), so GPG needs to use temp files to compute those
> lengths.

It would but rfc2440 allows partial length headers and newer version
of pgp know hoe to handle them. 

> Additionaly, I've found that PGP 2.6.3i and 5.0i put the signature
> packet *before* the litteral data packet in an encrypted and signed

Yes.  And this is a Bad Thing.  GnuPG knows hoe to verify them but
won't create them.  A wrapper program can handle this.

> I also added textmode support in the symmetric encrypting code and in
> the store code (this is not related to PGP 2.x compatibility, but it
> doesn't hurt :-).

Okay. I apply this.

I hope you won't give up hacking and testing GnuPG even if I have
rejected your changes.


Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

More information about the Gnupg-devel mailing list