pgp2.x is dangerous too (Re: PGP Employee on MKR)

[Adam Back]

Lucky Green <shamrock at cypherpunks.to> writes:
> On Fri, 24 Oct 1997 mark at unicorn.com wrote:
> > 
> > If you can explain the following, then I'll accept that my fears are merely
> > fantasies:
> 
> OK, I must be missing something. How can it be more evil if the email
> isn't automatically sent to the owner of the MK key than if the email is
> automatically cd'ed?

Uh.. I think you've hit on the center of the problem here.

Here's my take on it:

CMR is potentially dangerous because it can be abused; therefore make
things which are harder to abuse for government communications
snooping.

pgp2.x is potentially dangerous because it can be abused; therefore
make things which are harder to abuse for government communications
snooping.

I think pgp2.x is potentially dangerous too -- the only difference
being that no-one that I know was widely deploying policy enforcers
for it.

Yes even easy to write code has to be deployed -- deployment is the
larger part of the battle, clearly.  TIS has been selling GAKware for
years, and no-one much is using it, as one example.  Passing a law
over-night that everyone must downgrade to TIS GAKware is problematic
-- people will revolt, even companies who have no political stance,
just because of the hassle of it.

Interoperability matters.  If we can widely deploy software which
needs to `unpublished' to deploy GAK, we've built some additional
resistance to GAK.  (With Luckian outlook, this will be a delay rather
than a prevention, but it's still a net good).

Standards matter too -- if we widely deployed a Internet mail standard
(say OpenPGP:-) which would have to be modified in non-backwards
compatible ways to introduce government communications message
snooping, we'd have enormous resistance to GAK.  This is because it
becomes international -- if the US doesn't switch to GAK, then a
France which tries will face problems: cut themselves off, or not do
it, or attempt to do it, but have it unenforceable even for
non-technical users.

Now the main point isn't that CMR and policy enforcer is ever so
slightly more dangerous than pgp2.x, the point is that pgp5.x is being
widely deployed; and that people are switching from pgp2.x to 5.x
(especially due to limited backwards compatibility being used to
encourage move to non-patented algorithms).


Say, for the sake of argument, that OpenPGP adds a MUST or a SHOULD
feature to have some kind of forward secrecy.  Say this feature gets
deployed everywhere.  (I'm sure we'll all be 100% behind that one!)

Numerous anti-GAK features have been proposed.  PFS TLS, which as I've
shown can be authenticated via the existing PGP WoT is one way (easy
to bolt on to existing PGP SMTP agents -- another weekends hack at
most).  Providing opportunistic PFS inside the PGP message envelope by
sending new keys with messages, which may be used to reply in a
forward secret manner, and basing data recovery features on storage
recovery where possible are others.

Deploy such features.  Deploy such standards.

Imagine trying to revoke SSL standard to make it non forward secret.
(Government recovery of web traffic, yeah).  That'd be a tough one,
right?

I presume that is part of C2's motivation in delploying 128 bit web
servers, and 40 <-> 128 bit local proxies to uprate browser security.

> > 1. How PGP can prevent CMR being converted into GMR; their system builds
> >    all the code required to support mandatory encryption to FBI and NSA
> >    keys into every copy of PGP.
> 
> Agreed. And so did PGP 2.x and any version of PGP that allows for
> encryption to multiple keys. Anybody can take the 2.6 source and hardcode
> in a second recipient key.

This to me doesn't say "give up", it says: make something that is more
resistant to being abused by governments.  What the deployed base
does, and what the standards say is important.  What the government in
some tin pot dictatorship hacks into pgp2.x hardly matters, if the new
standard refuses to talk to it.

> The answer is that no PK crypto system can prevent being converted
> for GAK use.

It just isn't that black and white.  Some things are clearly much more
resistant than others.  Most anything can be subverted by governments,
but some things are harder than others.

> I read the recently proposed alternatives and fail to see how they
> would prevent GMR any more than PGP's solution.  All I saw were
> convoluted and frequently hasty designs, many of which lend
> themselves even more to GAK then what PGP did.

Pick a design, explain why it could lend itself to GAK, help improve
design to reduce danger.

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`