1994-07-08 - Re: Question: Key Distr. in realtimeo applications?

Header Data

From: kentborg@world.std.com (Kent Borg)
To: jrochkin@cs.oberlin.edu
Message Hash: 8049f46711214034cf0f75a7456d3779d0354c36e1c761260c0e86fa5dc17987
Message ID: <199407080551.AA04892@world.std.com>
Reply To: N/A
UTC Datetime: 1994-07-08 05:52:10 UTC
Raw Date: Thu, 7 Jul 94 22:52:10 PDT

Raw message

From: kentborg@world.std.com (Kent Borg)
Date: Thu, 7 Jul 94 22:52:10 PDT
To: jrochkin@cs.oberlin.edu
Subject: Re:  Question: Key Distr. in realtimeo applications?
Message-ID: <199407080551.AA04892@world.std.com>
MIME-Version: 1.0
Content-Type: text/plain


There are two ways around the problem of a faked public key.

1) spread it widely enough that it is hard to fake the several lookups
you might do before first using it (you gonna doctor every cypherpunk
posting I see which includes a key?  gotta have a good middle to not
get caught sitting there)

2) have a single well known key sign a copy of the key you want to be
accepted as legit--and if that is too busy a task for the very
important single key holder, just sign a few keys (one for Oberlin,
for example) and have *them* sign further keys (including a copy of
their signed credentials).  This signing of credentials can be
extended indefinitely.  (Apple uses this scheme with RSA coding in
their forthcoming mail support for the Mac--or at least did, I have
not played with the recent betas.)

And these two approaches work together.  If my keyring has dozens of
keys from the same organization, all signed with the same organization
key, it becomes very difficult to get me to accept a fake.  (Assuming
there is software support for easily doing this kind of checking,
something I don't think is in PGP, etc.)

Encryption of voice: same problems as other key authorization
situations, but often easier.  If I call my mother, I don't care what
key she uses, I will recognize her voice, how she speaks, and what she
appears to know--things that are not yet fakeable except by very good
actors with lots of time to study their roles.

One-time key, how to distribute to both participants: don't.  Let each
pick a random key and sent it to the other using the other's public
key--no need to use the same key in both directions, in fact seems a
bad idea.

-kb, the Kent


--
Kent Borg                                                  +1 (617) 776-6899
kentborg@world.std.com                                
kentborg@aol.com                                      
          Proud to claim 31:15 hours of TV viewing so far in 1994!





Thread