Technical Description of PGP 5.5

[Adam Back]

Lucky Green <shamrock at netcom.com> writes:
> 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.

Agreed.  But PGP Inc may be able to deploy their system better than
some lone hacker is able to deploy a perl hack.  And deployment of
pgp5.5 / 5.0 is required to provide automatic interoperability for
this.

(Yes I know you could bounce the mail, and demand a Cc: snoop at acme.com
to go with all mails to fred at acme.com, and use a lot of pgp2.x setups
to auto-encrypt to those recipients with pgp2.x crypto recipients, but
this is not as convenient).

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

Fine, a good, entirely separable functionality.

> >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.
> 
> Correct. But this isn't going to stop people from complaining.

You are right, it's not.

Just because things are possible, doesn't mean you should _do_ them,
nor attempt to massively deploy them.

If the pgp5.5 functionality is designed to provide companies with a
disaster recovery procedure (forgotten passphrase, or dead employee),
there are much better ways to do it.  We're not arguing against the
user requirement, just against the methodology.

> 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.

Sure, that works.  For now.

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`