Re: Question: Key Distr. in realtimeo applications?

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!

Kent writes:

| 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.

	Sending your otp by RSA reduces the security of your OTP to
that of RSA, since if your RSA key can be broken, the otp can be
obtained.  Since the problem is barely more difficult than factoring
your rsa key (or craking the one time idea password in use), there is
no security gain to the otp.

	otp's require that they be securely distributed.  Usually,
this means a courier with a briefcase full of cd-roms handcuffed to
his wrist, or some other similarly paranoid means.


Adam

-- 
Adam Shostack 				       adam@bwh.harvard.edu

Politics.  From the greek "poly," meaning many, and ticks, a small,
annoying bloodsucker.