1997-10-14 - Just say “No” to key recovery concerns…keep OpenPGP pure

Header Data

From: Tim May <tcmay@got.net>
To: Adam Back <zooko@xs4all.nl
Message Hash: c1581a1d2a9d5dde53740c3e117211cb55b39e284b581cde18b0c6c9692b690d
Message ID: <v03102800b06978017bc1@[207.167.93.63]>
Reply To: <199710141053.MAA03610@xs1.xs4all.nl>
UTC Datetime: 1997-10-14 22:59:56 UTC
Raw Date: Wed, 15 Oct 1997 06:59:56 +0800

Raw message

From: Tim May <tcmay@got.net>
Date: Wed, 15 Oct 1997 06:59:56 +0800
To: Adam Back <zooko@xs4all.nl
Subject: Just say "No" to key recovery concerns...keep OpenPGP pure
In-Reply-To: <199710141053.MAA03610@xs1.xs4all.nl>
Message-ID: <v03102800b06978017bc1@[207.167.93.63]>
MIME-Version: 1.0
Content-Type: text/plain




I have an even simpler solution to the problem of how the OpenPGP committee
should solve the key recovery/message recovery/corporate/GAK problem: Don't.

Just decide and announce that neither plaintext nor key recovery will be
part of the OpenPGP spec. This is a cleaner and simpler approach, and the
functions of encryption are placed front and center.

(Let some other task force deal with building some kind of "OpenGAK" or
"OpenSnoopware" program!)

That is, OpenPGP need only worry about providing a robust, secure, etc.,
open standard for end-to-end encyption (communication) and local encryption
(storage). Don't try to solve the "disaster planning" problem ("Alice hit
by a truck") by building snoopware/escrow into the core cryptosystem, and
don't try to solve the snoopware ("What is Alice saying to Bob?") desires
of companies either.

For comparison, we certainly don't see the world's telecommunications
bodies, committees, and companies working on a "conversation recovery" mode
to make the job of enforcing the U.S. Digital Telephony and similar
wiretapping desires.

Dealing primarily with communication and file security is what PGP has
historically focussed on, in all versions from 1.0 to 5.0 (not counting the
anomaly of ViaCrypt). Sounds fine to me. The "mission" of PGP and other
public key cryptosystems (until now) has been to secure communications and
files, not to provide mechanisms for corporations to monitor
communications. (Disaster planning, for "what if Alice gets hit by a
truck?" scenarios, are of course handled by having Alice lock up her
private keys in her safe, or perhaps her department manager's safe,
whatever. This is a dangerous security flaw, if the key is released, but
has the advantage that it's a fairly conventional recovery approach, and is
not built into the cryptosystem itself. Trying to solve this problem, that
of "backup keys" or "spare keys" floating around, is not easy in any
case...OpenPGP would do well to just avoid the issue and let conventional
disaster planning measures deal with the problem.)

If corporations, agencies, governments, etc., want to have access to
Alice's files, to Alice's communications to Bob, this is really a file
managment and archiving strategy problem, not something OpenPGP has to
concern itself with.

Keep it Simple, Stupid. KISS. Often the simplest approach to dealing with
complex specifications and conflicting desires is to just ignore them.

Let Big Brother and Little Brother try to get snoopware deployed when
OpenPGP is widely available.

Whether PGP, Inc. will go along with this is unlikely, but this doesn't
change the reasons for keeping OpenPGP true to the original aims of PGP.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."








Thread