1997-10-11 - Why corporate message recovery IS gak compliant (Re: Why Corporate Message Recovery isn’t GAK)

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: jon@pgp.com
Message Hash: c8f5341ad18c7435081d41b8896814767cbf018917189d3345ddda0999353016
Message ID: <199710110141.CAA06527@server.test.net>
Reply To: <3.0.3.32.19971010151206.00a122b0@mail.pgp.com>
UTC Datetime: 1997-10-11 02:04:13 UTC
Raw Date: Sat, 11 Oct 1997 10:04:13 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 11 Oct 1997 10:04:13 +0800
To: jon@pgp.com
Subject: Why corporate message recovery IS gak compliant (Re: Why Corporate Message Recovery isn't GAK)
In-Reply-To: <3.0.3.32.19971010151206.00a122b0@mail.pgp.com>
Message-ID: <199710110141.CAA06527@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Jon Callas <jon@pgp.com> writes:
> There are two things I will discuss in this missive:
> 
> (1) The assertion that Corporate Message Recovery is "just like Clipper"
> and why this is not true.

I won't even bother dealing indivdually with your arguments to this
one because you have just demonstrated again your ability to
simultaneously focus on hair splitting trivia, and ignore the whole
crux of the argument.

Suffice to say that it is not the details of the GAK (government
access to keys) system that the US government has tried to coerce
people to use that makes people not like it.  It's what it means: it
means that government will have access to keys.

We have had what some people term Clipper I through Clipper IV (or is
that V)?  The details and the names change each time.  And were you to
be their spokesperson you would be explaining in intricate detail how
"key recovery" is not "key escrow" and how therefor it is ok, and we
should all accept it.


The argument against pgp 5.5 is that it does 3 things wrong:

1. it is GAK compliant; it provides a ready to roll GAK system for the
US administration to try to leverage into place and switch on

2. it attempts to provide escrow features for transient communications

3. it doesn't differentiate between storage keys (which should be
escrowed to protect encrypted information stored on hard disks and
backup tapes) and transient communications keys which should if
anything be securely wiped after use

> Now then, the next topic is the fear that CMR will be used in some
> insidious government plot to slip in GAK everywhere.
>
> I worry about this, too. 

I'm glad that you acknowledge the very real problem.

> But I don't think it's feasible that CMR can be a stalking horse for
> GAK.

I notice that none of your reasons are technical.  I take this to be a
tacit acknowledgment that you have indeed built a GAK compliant system
with pgp5.5.

Let's have a look at these balances to see how comforting they are
given the lack of technical protection (being a cypherpunks I like
technical protections, they are so much more useful and concrete than
words of assurance):

> If the government wants to GAK-enable all PGP, they'll have to have
> a plan similar to this:
> 
> (1) Buy PGP, Inc. Since our worth is less than the black portion of the
> Federal Budget, this is not impossible. Would that it were otherwise. Heck,
> we're probably worth less than the black portion of New Zealand's budget.

Why would they have to buy the company?  They would just introduce
legislation to enforce _use_ of a feature you have already
thoughtfully included.  (A couple of people speculated that this early
GAK compliance may be the result of PGP Inc corporate investor
pressure (the share holder is god), or perhaps high level management
decision that this allows an easy route for PGP whatever the outcome
of the GAK wars: mandatory GAK PGP wins with it's early compliance, if
mandatory GAK loses, well PGP continues to cash in PRZ's reputation,
and PGP Inc's business client base).

My question to you is what is PGP Inc going to do when becomes illegal
to sell software which doesn't include mandatory GAK?  What're you all
going to do?  Break the law?  It'll be too late by then, unless you
have a corporate contingency plan of moving to Switzerland.  Do you?

> (2) Fire all the current development staff. This isn't very hard. All the
> new bosses have to do is round us up in a meeting and announce, "The next
> version of PGP will have a 40-bit export option." We'll say, "Not while
> *we're* working for the company!" They'll say, "Fine with us." Keep your
> eye on the secure resume server for clues of this event.

The company would survive with staff replacement.  Especially with
mandatory GAK as the regime.

> (3) Hire a new staff. This is one of the places that the plan might fall
> apart. We have such a hard time finding anyone who's qualified to work for
> us that we have reqs we can't seem to fill. I suppose, though, that they'll
> be able to find some people willing to relocate from Maryland.

No problem.  They'll just pay higher wages with the huge government
sell-out dividend reaped by being a early GAK adopter (via GAK
compliance).

> (4) Stop the OpenPGP process in the IETF. [...] If OpenPGP succeeds,
> then anyone can build an interoperable version of PGP, not just us,
> Highware, Systemics, etc.

Stopping the OpenPGP process doesn't sound necessary, if I read your
other post correctly PGP Inc would like to persuade the IETF to put
GAK compliance features in the OpenPGP standard as a MAY right now.
If you have your way, it'll be ratified by the time GAK comes.

You might like to consider this thought also:

Even if you personally believe that PGP Inc will stall at mandatory
GAK, and cease trading rather than do it, or even if you personally
will resign (I can't see that anyone's resignation helps us after the
fact):

	other OpenPGP implementors may not.  TIS or IBM or one of the
	other bona-fide GAKware government sell out types will take
	the opportunity to create an interoperable mandatory
	government access to key system.

This is a BAD thing.  You could prevent that.  But you're not, you're
helping it head to fruition.  You will have to live with your
conscience if GAK happens through this route.

> (5) Wait until bitrot makes all those existing copies of PGP stop
> working.  I could make a few catty remarks about how quickly
> existing software stops working on new releases of OSes, but you've
> probably thought of them yourself.

Mr linux hacker will figure it out.  Mr windows user won't.  There are
more Mr windows users.

> There are also a few details left, like shutting down all those
> international FTP sites, but hey, they're the government, they're
> omnipotent.

This game isn't about Mr crypto-anarchist, linux hacker, it's about
mass market software, about what individuals and companies are using.

The spooks know they can't stop "live free or die" types using
steganography even after mandatory GAK.

Won't make it any less painful for those who don't have the nerve or
technical expertise.


I would say that I am not trying to be vindictive, or anything here,
but you are _so_ easy to criticize, and I am trying to do what I can
to encourage PGP to salvage the situation.

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