1997-10-23 - Re: Technical Description of PGP 5.5

Header Data

From: “William H. Geiger III” <whgiii@invweb.net>
To: cypherpunks@toad.com
Message Hash: dc146763874aa85796ab8de5d4d1faa76229cda967ef6920e03374f26cc32afe
Message ID: <199710230735.DAA21516@users.invweb.net>
Reply To: N/A
UTC Datetime: 1997-10-23 07:41:44 UTC
Raw Date: Thu, 23 Oct 1997 15:41:44 +0800

Raw message

From: "William H. Geiger III" <whgiii@invweb.net>
Date: Thu, 23 Oct 1997 15:41:44 +0800
To: cypherpunks@toad.com
Subject: Re: Technical Description of PGP 5.5
Message-ID: <199710230735.DAA21516@users.invweb.net>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

In <3.0.2.32.19971022210316.00727944@netcom10.netcom.com>, on 10/22/97 
   at 09:03 PM, Lucky Green <shamrock@netcom.com> said:

>At 07:12 AM 10/15/97 -0700, Kent Crispin wrote:
>>Correct me if I'm wrong, but this seems to imply that the CMR fields 
>>in the key structure are really just a convenience -- if PGP, Inc. 
>>didn't write an smtp filter that enforced a CMR key, someone else
>>(say a firewall vendor) could do so easily, defining whatever 
>>relationship between keys they wanted.

>Anybody with half a brain, a copy of perl, and the PGP 5.0 source from
>http://www.pgpi.com/ could write a similar filter in a matter of hours.

I made this point at the very begining. Source code is not even needed,
all one needs to know is the encryption & signature packet formats to be
able to pull the keyID's.

>I am going to install PGP's SMTP filter on my box. To make it impossible
>to accidentally send unencrypted mail to certain people. :-)

I already have this inplace as a Rexx script on my E-Mail client. :))

>>To make that a bit stronger, it seems like *any* model that uses 
>>persistent encryption keys essentially enables CMR-like functionality 
>>in a smtp filter -- it could be done using pgp 2.6.

My set-up works with 2.6->5.0. It's just not persistent keys but the
ability to encrypt to multiple recipiants. Of cource even without these
features this functionality can implemented by moveing encryption to the
server. Only signing & decryption need to be on the client machines. 

It may even be more efficent in a corporate enviroment to do so. There are
performance questions in a high volumn enviroment but I have developed
techniques that greatly enhance the perfomance of PGP when working with
large keyrings. I know C2-Net has done work with their Stronghold product
for supporting hardware based encryption to improve performance on high
volumn servers, it would be intresting to see how well these cards would
lend themselves to PGP.

>Correct. But this isn't going to stop people from complaining.

>PGP 5.5 is considerably better than PGP 5.0. The LDAP support alone is
>reason to upgrade. The UI is improved and if you don't want to use
>message recovery, just don't turn it on.

I will agree that 5.5 is an improvement but to be honest I am not that
crazy about it. Not that all of it is PGP's fault alot has to do with the
OS it runs on. NT just isn't ready for prime time. I have my own GUI I
designed for PGP on the OS/2 platform so I am a little biased in that
area. :)

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNE7+aY9Co1n+aLhhAQFhwgP/SdJSeNgbG/SRgR15gwtb22QFOF/VBEL6
K047yXYEwJ/2Vd/zEwJ8AU/6ycVawtGMFpIGyLQHG91ATVear7CSHmsa6KMPH7EC
dtK2bbEQlpJsgGbQpXNt6gHOuKYRZIXp65XIlEvu8qW3CJLUGz+RTNnKOAIFkUe2
JWWYRj7N5Wc=
=xwCN
-----END PGP SIGNATURE-----






Thread