From: Raph Levien <s_levien@research.att.com>
Date: Tue, 16 Jul 1996 03:08:24 +0800
To: "Timothy C. May" <tcmay@got.net>
Subject: Re: How I Would Ban Strong Crypto in the U.S.
In-Reply-To: <ae0efb9f020210046227@[205.199.118.202]>
Message-ID: <31EA4E91.37B3@research.att.com>
MIME-Version: 1.0
Content-Type: text/plain


Timothy C. May wrote:
> 
> At 12:18 AM 7/15/96, Dave Banisar wrote:
> >Its now up at http://www.epic.org/crypto/key_escrow/wh_cke_796.html

   Thanks to Dave for posting this URL. This is a _very_ important 
document, and I would recommend that all concerned cypherpunks read it 
carefully. Unlike many of its predecessors, it is clearly written and 
quite upfront about the "administration's" goals.

> Thanks. I took an initial look, and it looks like the same old stuff.

   It's not. There's a lot in this document that hadn't been clear to me 
before. I will try to summarize the highlights (these are all my 
interpretations, not actual points made in the document).

1. The battle over whether applications can contain strong encryption 
algorithms has basically been lost. For example, SSL-enabled 
applications are widely available over the world, thanks in large part 
to the work of Eric Young. The same will happen for any other encryption 
protocol that catches on.

2. The battle for key management has not yet been fought. The lack of a 
key management infrastructure is the main reason why people don't use 
PGP widely. This is demonstrated quite clearly by the fact that only a 
few of the people I correspond with, including many premail users, 
actually encrypt messages on a routine basis. If the key management 
stuff were in place, it would "just work."

3. Anybody can write an application that supports strong encryption 
algorithms. Witness SSH, a very impressive and useful program, which was 
basically done by one person, Tatu Ylonen. However, building a key 
management infrastructure will take lots of money, hard work, and 
cooperation.

3a. Consider a future scenario in which a key management infrastructure 
allowed big, unescrowed keys to be distributed widely, but that export 
controls on clients prohibited the use of secure symmetric algorithms. 
Such a situation would not be stable - the incremental cost of 
uncrippled clients would be so small, and so tempting, that they would 
spread like wildfire.

4. Thus, the best leverage for the TLAs to win is to guide the 
development of a key management infrastructure with the following 
property: if you don't register your key, you can't play. I believe that 
this is the true meaning of the word "voluntary:" you're free to make 
the choice not to participate.

5. This is _important_. If you can't get the keys for your 
correspondents, you can't use encryption. If they build a key management 
infrastructure that actually works, people will use it.

6. Export is a two player game. The other country has to allow import of 
the stuff, too. If the Burns bill passes, the "administration" would 
strong-arm other countries to prohibit import of strong crypto, still 
leaving US developers with no market.

7. Building this stuff is too much of a task for the TLAs. They tried it 
with Clipper, and it failed. They hoped that building the Tessera card 
would be enough - that once they threw it over the wall, it would be 
eagerly snapped up by industry.

8. Thus, they're going to cajole, bribe, and coerce software companies 
to play along. This fact is quite nakedly exposed in the document (good 
thing the injunction against the CDA is still in force :-).

[much, much elided from Tim's post]
> ... and by opposition to Clipper I,
> Clipper II, and now Clipper III.

Is this Clipper III or Clipper IV? I seem to have lost count.

> A bunch of Congressmen, including the axis supporting the Burns bill,
> obviously are not part of this emerging consensus.

So it's a "rough consensus" in the spirit of the IETF :-)

> I would push hard on Netscape, Microsoft, Novell, Sun, Apple, and the other
> companies (but mainly on Netscape and MS, for obvious reasons) to bundle in
> "trusted third parties" and all that GAK stuff. Bundle it in, make it easy
> to use, make it easy to export, make it easy to spread in crypto-hostile
> countries, and hope like hell that it undermines the push for PGP and
> S/MIME.

You can count on the fact that NMNSA&c are already being wooed quite 
sweetly.

Don't put too much stock in the push for PGP and S/MIME. Five million 
dollars later, PGP 3.0 is still stuck in the mud. S/MIME has serious 
protocol weaknesses that are still not being addressed. But, most 
importantly, neither of these systems can actually be used on a 
widespread basis, because of the lack of a key management 
infrastructure.

> Don't be fooled.

Who? Us cypherpunks?

Raph