1997-11-01 - pgp5.x bashing (Re: [SURVEY] pgp5.x / pgp2.x users)

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: cypherpunks@cyberpass.net
Message Hash: 50f538d9b7d9e322a55e123c2c81ed97fa19be4925797415d0b934ecb2c13714
Message ID: <199711012117.VAA03414@server.test.net>
Reply To: <d7398092218ec328be03256d0d8c83a9@anon.efga.org>
UTC Datetime: 1997-11-01 21:37:15 UTC
Raw Date: Sun, 2 Nov 1997 05:37:15 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 2 Nov 1997 05:37:15 +0800
To: cypherpunks@cyberpass.net
Subject: pgp5.x bashing (Re: [SURVEY] pgp5.x / pgp2.x users)
In-Reply-To: <d7398092218ec328be03256d0d8c83a9@anon.efga.org>
Message-ID: <199711012117.VAA03414@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Anonymous writes:
> >The question has come up on ietf-open-pgp as to how important it is
> >for the OpenPGP standard to support backwards compatibility with
> >pgp2.x.
> 
> Very. 5.x right now is nothing but annoying. I can understand
> wanting to use the new algorithms. However if the authors want to do
> that and literally force people into upgrading then they need to
> make sure that every platform which had a version of 2.x has a
> version of 5.x available, and they need to stop breaking *every*
> script and program which calls PGP. If they release a version of PGP
> for one platform before they do others and the new version is
> incompatable with the old for all intents and purposes, they're just
> feeding OS wars, frustration, and hostility.

I think it is somewhat understandable that the windows and mac
versions work well before the unix versions, even if painful.  The way
that `make install' over-writes your pgp2.x binaries is mildly
annoying also.  (And the way the binary can't handle being renamed to
pgp5 -- insists on being called pgp which makes it more difficult to
have it coexist).

(An aside: I understand the linux version (that is if you use the unix
version under linux) is supposed to be free for any use (even
commercial) at least that's what Phil Zimmermann said sometime back --
this was to humor a Richard Stallman.)

> >The IETF generally likes to steer clear of patented algorithms as
> >MUSTs in standards.  This encourages implementations, etc.
> >(Personally I'm pretty keen on this point, though I would like more
> >backwards compatible pgp5.x implementations -- I've already received
> >emails I can't read without resorting to the pgp5 command line app,
> >which doesn't work with my mailer integrated system.)
> 
> That's exactly my situation. I figure, however, that if somebody is going to
> send out broken email I won't bother kludging around to read it no more than
> I will go start X11 and fire off a 20 MB browser (Communicator) because some
> moron doesn't know how to use HTML as it was originally designed. I'm 
> personally appalled at the number of Cypherpunks using a version of PGP
> which is completely incompatable with previous versions and outrageously
> annoying to use unless you run Windows since it breaks everything which is
> integrated.

Hmm.  It's not _completely_ incompatible, it's only broken.  If the
pgp5.x user uses an RSA key it works ok.  So people who want to
interoperate should generate two keys, one DSA/EG pair, and one RSA
key.  Use RSA for talking to pgp2.x, and DSA/EG for talking to 5.x.
(Or use RSA for everything, but 5.x has some security advantages
(better 0xdeadbeef resistance, no fingerprint spoofing problem,
separate signature and encryption keys, key expiry, etc)).

Problem is pgp5.x doesn't automate this.  It could.  It doesn't I
think because they are trying to get people to move away from RSA,
also perhaps (speculation here) because they are trying to get you to
pay for the new version.  (Though there are still freeware versions,
commercial users will need to switch, and some people may pay so they
get tech. support, etc.)

I figure a more friendly way for pgp5.x to behave would be to generate
both sorts of key (RSA and DSA/EG) and automatically do the right
thing depending on public key type of person being communicated with.

> I think the major problem with 5.x right now as it stands is the complete
> lack of support from http://beta.pgp.com, the forced command-line
> incompatabilities, 

I wouldn't say this is "forced", more that they haven't gotten to it
yet due to time pressure.  It's probably quite fiddly to get right.

> and the lack of a stable multiplatform version. Add to that the CMR
> debacle.

Uh yeah, well you won't get any arguments from me on the CMR front;
CMR is basically clipper VI (or whatever the clipper version is now).

> Face it, PGP Inc. screwed up. I think it's ultimately going to be the job of
> Cypherpunks outside of the Land of the Freeh to clean up their mess.

If you're interested, watch www.systemics.com, and enigma
http://www.cs.ucl.ac.uk/staff/I.Brown/; presently they'll add pgp5.x
compatibility.  enigma and systemics cryptix is in _java_, you can't
get much more portable than that.  enigma works with any configurable
SMTP / POP3 MUA (netscape, eudora (I presume), etc)

> Has anyone considered hacking up 2.6.xi to handle the new format? It
> would have to be saner than 5.x is at this point. I would try, but
> I'm in the Land of the Freeh where you put your backside on the line
> to write any crypto software at all.

Probably someone will do this if the CMR debacle carries on.  I have
already heard some speculation on an alternative source tree branching
off from pgp2.6.x.

Watch ietf-open-pgp too, it'll be interesting to see what happens if
the long waited for draft from PGP includes CMR.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`






Thread