what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))

Adam Back adam at cypherspace.org
Sun Mar 31 19:34:35 EST 2002


Hi

I've trimmed the Cc line a bit as this is now focussing more on GPG
and not adding any thing new technically for the excluded set.

On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote:
> The OpenPGP spec handles compatibility issues quite well.  
> The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x
> isn't OpenPGP.  PGP 6 and 7 aren't really OpenPGP either, but
> they're generally close enough for all practical purposes.

I don't see how this is a useful distinction.  They are self-evidently
not close enough for practical purposes as evidenced by the fragmented
user base and ongoing problems you experience if you try using PGP.

Back in the days of pgp2.x I used to receive and send a fair
proportion of mail encrypted with pgp; these days it is a much lower
proportion, and a rather high proportion of those fail.  It's not like
I'm using old software or failing to try what is reasonable to get
messages to work.  Even with my fairly complete collection of PGP
versions you saw the results.  Imagine how much worse it will be
between people who do not upgrade frequently or take such defensive
strategies.  So you say upgrade already.  However as I think I have
demonstrated, I follow this strategy myself and as you can see it
doesn't work either.

> PGP 7 or GnuPG with the IDEA plugin can handle messages from any
> version of PGP, OpenPGP or not.

I can't speak of PGP 7's behavior in this discussion as it is not
available for the operating system I primarily use (linux) as far as I
am aware.

> I doubt it's intentionally hidden, though it's certainly a pain to
> find.

I would characterise the situation as intentionally frustrating
attempts to use IDEA.  The whole point of the little exercise of
stripping out the idea.c, making it a separate dynamically loadable
module, tucking it away in a FAQ where you are pointed to lectures
about how software and algorithm patents are bad is _specifically, and
explicitly_ to discourage use of patented algorithms (and in this case
of the idea.c implementation) and to encourage people to do lobby
about the patent madness.

Campaigning against patent madness is a good cause in itself but not
when it gets in the way of privacy to the point that people are
sending messages in plaintext.  After all what is GPG's primary
purpose: is it an email security software package focussing on
security, or a platform for promulgating political views.  I view the
exclusion of idea.c from GPG as basically a security bug of higher
severity than for example PGP2.x's manipulable fingerprint, or
pgp5.something's (before it got fixed) unsigned ADK bug packet, or the
potential buffer overflow in ZLIB.  This bug is worse because it
reproducibly and frequently causes people to send mail in clear text.
The other bugs are by comparison less dangerous, yet they (the two
more recent ones) were fixed by NAI, and GPG and other PGP software
maintainers with rushed over-night hot fixes.

I would suggest this bug would be best fixed in GPG by:

a) including IDEA as a default option in GPG -- the ASCOM patent
license is really very liberal for non-commercial use, and 

b) if that goes against the GNU philosophy to the extent that it is
worth causing hinderance to hundreds of thousands of users who
practically are _going_ to want it they could at least make it a
configuration file option and ship it as other crypto libraries such
as openSSL do.  (I'm not sure how it hurts the anti-patent stance to
do this -- gnupg.org is after all _already_ distributing idea.c, just
separately).

Adam

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



More information about the cryptography mailing list