Re: Technical Description of PGP 5.5

-----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-----
participants (1)
-
William H. Geiger III