From: David Jablon <dpj@world.std.com>
Date: Thu, 28 Aug 1997 13:24:19 +0800
To: James A Donald <cypherpunks@toad.com
Subject: Re: Monkey Wrench into the works
In-Reply-To: <199708271737.KAA26892@proxy3.ba.best.com>
Message-ID: <3.0.1.16.19970828005458.3ae7e2f2@world.std.com>
MIME-Version: 1.0
Content-Type: text/plain



James,

You're rebuttal to Myron's message is simplistically
elegant, but just as wrong as the original posting.

It is perfectly fine to secure a relationship using shared
secrets ... in some situations.  You are wrong in implying
that shared secrets don't work anywhere.  Myron is of course
just as wrong in implying that his (or any) shared secret
scheme will replace the many needs for a public-key
infrastructure.  (As the details on his scheme or intended
applications aren't available, I have no further opinion on it.)

"Myron Lewis" <mrlewis@keygen.com> wrote:
> We invite you and everyone on the list [...] to visit the KeyGen
> webpage, www.KeyGen.com and learn about Automatic Synchronized
> KeyGeneration(TM).  If you think you recognize it as something you have seen
> before, you're close but wrong.
>
> We are obviously biased, but we feel strongly and so do many others, that
> ASK will solve many of the security problems presently under discussion.  In
> time, it will probably sink Key Management and Certificate Authorities.

On 8/27/97, James A. Donald replied paraphrasing Ben Franklin,
(who really knew very little about cryptography):
>What one man knows, nobody knows.
>What two men know, everyone knows.
>Shared secrets just don't work.

Clearly in many cases parties must share secrets.
You and your bank keep mutual secrets about your money.
You and your doctor keep mutually secret medical data.
It's hardly a burden in many cases to keep a few more
secret bits on a per-user basis, if it can help make
things a lot more secure.

For example, you might look at <http://world.std.com/~dpj/>
to see what just a few shared secret bits can really do.
The EKE, SPEKE, and related methods leverage a lowly password
as a strong factor in authentication.

Public-keys and CA's are ideal and necessary for many things,
like mutually anonymous short-lived relations.  The
"one-night-stand" web credit transaction comes to mind.
For long-term relationships, the extra overhead of
additional one-on-one key pre-agreement may often be
insignificant, and I dare say that, in *some* cases,
public-key encryption can be made almost irrelevant.

The best methods of course usually combine these different
paradigms as needed to achieve the most security and
efficiency.

------------------------------------
David Jablon
http://world.std.com/~dpj/
dpj@world.std.com