From: Adam Back <aba@dcs.ex.ac.uk>
Date: Mon, 13 Oct 1997 12:04:59 +0800
To: zooko@xs4all.nl
Subject: the GAK meme war: beware of NewSpeak and Minitru memes (was Re: Is Adam Back falling for one of Minitru's tricks?)
In-Reply-To: <199710121557.RAA13185@xs2.xs4all.nl>
Message-ID: <199710130339.EAA01978@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Zooko Journeyman <zooko@xs4all.nl> writes:
> 
> Dammit Adam.  I respect your opinion and your knowlege about
> these issues, but I think that you've been fooled by Minitru's
> machinations.

I'm all ears to such an alarming prospect.  I also respect the
Journeyman's insights (to return the compliment :-)

We have to be watchful that we don't start using NewSpeak, and to not
get inadvertently drawn into perpetuating the GAKkers insidious false
memes -- often out-right fallacies -- spread by the GAKkers as part of
their mandatory GAK campaign.  It is often staggering how successful
the GAKkers are in spreading these memes, given each GAKker meme's
inherent fallacy once it is examined at all closely.  Often the terms
the GAKkers choose for their memes are hijacked existing technical
terms with nice wholesome sounding rings to them.  "key escrow", "key
recovery", etc.

Even in these circles, on cypherpunks, we see it.  People using the
NewSpeak terms "key escrow", "key recovery".  Having the press release
their memes as "news", and having the press give the photogenic chief
GAK spokesperson Freeh lots of air time helps the GAKkers cause no
end.  The "four horsemen of the infocalypse" being the GAKkers other
favourite false meme -- that you can prevent criminals using crypto by
restricting the law abiding populace's access to non GAKked crypto.
And another false meme is that export controls are designed to stop
terrorists obtaining crypto -- what they are designed to do is hinder
companies building in crypto, by with-holding 50+% of the market place
for strong crypto from US companies, and by spreading FUD.

The efforts of Tim May and others to provide alternate non-NewSpeak
terms and to propagate those helps a lot.  Cypherpunks have had some
success in this area.  Carl Ellison's 'GAK' acronym is doing well,
other cypherpunks PR wins being the Big Brother Inside logo & sticker
campaign, KRAP acronym (dumbly named by the GAKers themselves: Key
Recovery Alliance Program).  Also "four horsemen of the infocalypse".

(My reason for not attributing all these pro-crypto phrases and memes
is that I don't know where they all came from -- the majority I think
Tim is responsible for, but like all good memes they become part of
the langauge, like the rhetorical question "Who is John Galt?" in Ayn
Rand's novel.  People often don't know the origin).

Another succesful cypherpunks meme is to continue calling GAK GAK in
the face of new editions of the NewSpeak dictionary handed down from
DC, where new PR terms are given to new attempts at GAK.  For example,
first there was Clipper I, which backfired to the extent that
`Clipper' ended up meaning `big brother wants to read your mail, and
tap your phones'.  Then they tried a new name, cypherpunks called it
clipper II, which partly blew the GAKkers cover, as they were trying
to sneak it through under a different name.  We are now on Clipper IV,
or V, I've even lost count!  We're still calling it GAK, or Clipper
XII or wherever the count is.

Anyway, lets discuss Zooko's insights into this NewSpeak issue:

> Minitru would _like_ for the world's businessmen to be presented
> with a choice between "brittle" crypto-- private keys held solely by
> owners, plaintext available solely to recipient, where every
> forgotten password, missed keystroke or disgruntled saboteur means
> the company loses valuable data permanently-- or GAKked crypto where
> these problems of brittleness are solved by Big Brother paternally
> providing backups when you find yourself in need.

I agree with that 100%.  You can see that meme being spread in press
releases, and in quotes from Freeh etc.  Jon Callas was perpetuating
this meme in his post about PGP's controversial business snoopware.
The whole "key recovery" PR renaming of GAK was intended to exploit
this spin:

 "businesses need access to their information, therefore they need the
  government to have access to their communications".  

Now hold-on-there one minute!  Why should businesses give the
government access to keys for recovering their own data?  Surely they
would keep backup copies of their own keys in their company safe, or
with their lawyer, or whoever the want!  Also (and it simply _amazes_
me that people do not notice this switch), companies data is on their
frigging disks! .. not flying around in transit bouncing between flaky
SMTP servers.  Lucky Green occasionally steps in to correct this myth.
Tim May did a nice expose of this myth yesterday.  The cunning GAKker
ploy that so called "escrow agents" or "trusted third parties" would
be "independent" was just so much fluff to divert criticism from
giving keys directly to government.  It means the same thing, and the
NSA reserves rights to the whole master key database anyway. (TTP
being another GAK term, an oxymoron if ever I heard one).

> In reality neither of these is an acceptable alternative for 
> serious use of strong crypto in business.  Escrow is a 
> valuable business concept, which was invented by businessmen 
> centuries ago and has been used ever since because it 
> provides significant value to the participants who voluntarily
> enter into the escrow contracts.  In the context of the 
> information age and crypto, escrow will be one of the basic 
> building blocks of the new era, both for basic business 
> purposes-- serving the same purpose that escrow has always 
> served but with heightened importance to pseudonymous, global 
> commerce-- and for building cryptosystems which are robust in
> the context of data being shared among many people (e.g. a 
> company).

Yep agree.  So long as we're talking about escrow of data stored on
disks.

I do not believe there is a case for escrow of communications in
transit.  I have been arguing that the most secure, and least GAK
friendly way of implementing escrow of archived email communications
is to decrypt the communications and store them with an escrowed
storage key.

> The issue is not how many people are given access to your keys
> or your data.  The issue is whether you maintain your right to
> control who those people are (including, but not limited to, 
> your right to decide that you will be the only person with 
> access), or whether others with delusions of grandeur and 
> obedient police forces can compel you or trick you into giving
> them access.

I agree with this statement also.

However some of the technical issues feed back into the political
process, and mean that it is dangerous to build certain types of
escrow systems, because they can be useful to GAKkers.  PGP Inc's
pgp5.5 and SMTP policy enforcer is 100% GAK ready.  It could be used
to implement a GAK system tomorrow, for example for the Chinese, or
Singaporeans who seem to want GAK, if PGP could export it to them.  We
_know_ the USG/NSA/FBI want to have mandatory GAK also.  Is it really
wise to hand them software and an installed user base on a plate like
that?

So I am also arguing against systems which are GAK compliant in this
way.

You will notice that a central theme for the GAKkers is that they want
to snoop communications, and so they naturally enough primarily want
access to communications keys.

Well this functionality is clearly not required for business data
recovery, nor even for recovery of archived email (when it is
re-encrypted with different storage keys, or just decrypted and stored
in plaintext).

So as long as you build corporate data recovery systems which truly
only recover storage keys, we're all fine and happy.


The meme that you need to have escrow of keys used to protect
communications in transit in order for a company to retain recovery
capability of it's employees mail folders is an especially tough one
to kill.  Even you, Zooko, and PGP Inc are guilty of that one.

One problem with this meme is it didn't have a label for a long time,
there was no term which described the problem, so it got lumped in
with CKE (Commercial Key Escrow) or CAK (Company Access to Keys) which
have much less negative overtones.  The chant "CAK good GAK bad" is
burnt into many peoples brains.

PGP Inc kindly provided a label for this problem, doubtless in their
minds at the time it was a friendly term: it is 

	CMR or "Commercial Message Recovery"

However there-in lies the precise same fallacy that the GAKkers are
promulgating with the "key escrow" and "key recovery" memes, that you
somehow need escrow of transient communication keys to access data
stored on your frigging disk!

PGP have propogated the GAKkers "key recovery" fallacy into the
corporate world with their CMR term, and GAKware implementation.  CMR
sounds reasonably palatable because they, like the GAKkers, chose it
to sound positive.  The sad thing is they probably didn't even realise
they were being fooled by the Minitru "key recovery" meme still, so
powerful was the meme that it blinded them to the falacy.

One problem with CMR is that it is a security flaw; it is bad security
practice to put second doors into transient communications, and that
it is GAK compliant.  And CMR is GAK compliant because if you do what
PGP have done with their CMR implementation, you have done want the
GAKkers want you to do with their "key recovery" and "key escrow"
campaigns.  You have implemented something which provide them on a
plate a really slick smooth migration path to mandatory GAK.

"GAK compliant" is the term I coined to express this aspect of the
problem with CMR.

We could kind of use a term for CMR which expressed it's negative
aspects, it is basically the technology the GAKkers want you to use
but being used for Companies.  This is what the GAKkers were trying to
do with the KRAP (Key Recovery Alliance Program) which was clipper
IV(?)  Only now PGP are inadvertently doing it for them.

Candidates which explain what CMR really is are Tim's "snoopware", or
perhaps "GAKware".  GAKware seems like a fair description, and is a
little harsher than snoopware.  It seems a fair description because it
is basically GAK enforcement technology being offered for sale to
companies under the guise of "data recovery".

> Don't let Minitru continue to confuse the issue-- you'll be 
> left with nothing but false alternatives.  Escrow is good and 
> necessary and inevitable-- ask any businessman.  GAK is not
> escrow.  Escrow is not GAK.

The above is the point were we diverge, and I think it is you, Zooko,
who has been conned by Minitru, or at least by PGP Inc, which was in
turn conned by Minitru.

Now that we have the terms we can express the problem concisely:

- Company data recovery of stored data is good -- companies need
  availability of their data

- GAK is bad -- because GAK means governments wanting master snoop
  keys into your messages, so that they can keyword scan them on
  fishing expeditions

- GAKware used for commercial applications is bad, because it provides
  the GAKkers with a deployed software base

- GAK compliancy in GAKware/snoopware is bad because it provides the
  GAKkers with a smooth migration path from:

	no GAK -> business deployed GAK -> mandatory GAK

  where business GAK is the process PGP Inc are starting right now by
  deploying GAK compliant software.

- Companies should acheive recovery of encrypted stored copies of
  communications which are encrypted with transient communications
  keys by encrypted stuff on disks with "storage keys", and stuff in
  transit with "communications keys".

- Communications keys should be short lived, the shorter lived the
  better, because this is the antithesis of GAK: not only can the
  government not snoop your communications, but they can't get you to
  decrypt them afterwards, because you won't have they keys.  (Forward
  secrecy being basically that you delete keys after use, or after some
  tunable, relatively short time period, 1 hour, 1 week, etc)

Say no to PGP Inc GAKware.

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`