1994-11-28 - Re: Transparent Email

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 4fd2e121b36586fe3bdd4cba1c2e8a8ef4f7b6a07933c17399aeafa0b1c0d92d
Message ID: <199411282252.OAA01960@largo.remailer.net>
Reply To: <199411280834.CAA00176@omaha.omaha.com>
UTC Datetime: 1994-11-28 21:53:29 UTC
Raw Date: Mon, 28 Nov 94 13:53:29 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Mon, 28 Nov 94 13:53:29 PST
To: cypherpunks@toad.com
Subject: Re: Transparent Email
In-Reply-To: <199411280834.CAA00176@omaha.omaha.com>
Message-ID: <199411282252.OAA01960@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   The big problem 
   with key distribution is the web of trust:  who gets to decide which keys 
   are good?

This whole area of key distribution has generated much confusion.  A
perfect world is described, and then everyone is assumed to
participate in achieving this world.  This approach of generality,
however, is notably more complicated than a world where responsibility
for security is partitioned, where  each user does not have to worry
about all the possible systemic security issues.

Proposition: You don't need to be responsible for making sure that the
other person is being spoofed; that's their responsibility.

A common situation where this proposition makes a significantly
simpler system is exactly in the case described, where you and your
email correspondents wish to exchange keys.  Suppose, in addition,
that you two met online and that your only channels of communication
are electronic.  The goal here is to create persistence of identity;
identification with a physical body is not needed.

In the PGP case you start with your own key, which you trust, then
look for a chain of signatures to the destination.  This chain can be
rather cumbersome to produce.  It's overkill, as well, since all you
really needed to know is that the key was not being translated on your
own end.  The PGP trust chain largely accomplishes that, true, but not
as simply as possible.

Alternatively, you save the first piece of email that you receive from
your correspondent; it has a digital signature on it.  Now _by
whatever means_, you obtain a public key by which to verify that
signatures on email you receive are the same.  You yourself need to
ensure that you aren't getting spoofed; you can do this by, say,
having your correspondent send mail to two different locations, or by
using a second channel to obtain the key by, or by using a PGP trust
chain, if one is available.

The original model for public key communications seems to have been
one channel with an interposer.  The real world is much more
complicated than that.  One can obtain good protection, at least as
good as a trust chain, by crossing organizational boundaries.  The
argument that trust chains are better because they are cryptographic
carries no weight; the decision at each link to make a signature is of
social, not cryptographic, character.

In particular, the design of PGP that ties key management inextricably
to encryption is bad and will contribute to an inflexibility that will
eventually sink PGP if it is not corrected.

   Perhaps we would have 
   a default web, which would have everyone's key in it.  

This is a really bad idea.  Some "public" keys should not be made
public, but rather revealed only to the correspondent.  Forward
secrecy is the reason.  If the public key has never been in the
possession of an opponent, and assuming the results of the public key
operation yield little or no information about the modulus, then when
the keys are changed and destroyed, no amount of factoring can find
the private key because the public key isn't around to factor.

Eric





Thread