Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!dla
From: dla@athena.mit.edu (Don Alvarez)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  RSA Encryption on the Internet
Summary: How can you trust public keys?
Keywords: RSA, Encryption, Public Key
Message-ID: <10159@bloom-beacon.MIT.EDU>
Date: 28 Mar 89 18:56:24 GMT
References: <8903222040.AA03642@braden.isi.edu> <10061@bloom-beacon.MIT.EDU> <7432@phoenix.Princeton.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: boomer@space.mit.edu (Don Alvarez)
Distribution: usa
Organization: Massachusetts Institute of Technology
Lines: 69

In article <7432@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU 
(Dan Bernstein) writes:
>In article <10061@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes:
>Let's say X wants to send a message to Y. [...]  X [uses his private key
>to encrypt a message], signs it, encrypts it by Y's public function, and
>sends it to Y. Y then receives it, decrypts it by Y[-private], checks the
>signature to find out X's identity, and then [decrypts the message using
>X's public key].
>
>X can be confident that only Y can read the message since only Y knows
>Y's decryption function. Y can be confident that only X could have sent
>the message _since_only_X_knows_X's_decryption_function_ ---otherwise the
>final message would be garbage. Thus public-key systems [...] provide sender
>authentication as well as privacy.
>
(emphasis added)

It is true that only X knows X's decryption function, but only X and the
public key directory know X's PUBLIC key for certain.  Everyone else has to
look up the public key in the directory service.

>How does this apply to the directory service D? There is only a single
>encryption function, ED, that must be distributed widely. This single
>key becomes common, public knowledge; [...] the directory service can then
>send out *signed* messages containing further keys.

I agree that if you only have one single directory service you can handle
things as you suggest.  On a network the size of the internet, with 10^5
or so people and many more companies, organizations, services, etc., each
needing their own keys, no one machine could possibly handle all the traffic
needed to dispense all the keys for everyones mailer and fileserver even if
keys have extended lifespans and caching is allowed.  You would kill the 
network with the volume of packets needed to handle the requests.  

Directory services need to be local and hierarchical, exactly the way
nameservers work on the net today.  That means if you want one single
directory service key, you have to give the private part to every
nameserver manager everywhere in the country.  Guess how long that
will stay secret.  You can't give different local nameservers
different keys without losing the generality of your single key.  Also,
consider what happens if somebody *leaks* your single key.  Every
operating system on every computer on the net has to be recompiled for
the new server key.

You can *perhaps* assume that there is a single directory service for looking
up local directory services, as in "who is the directory server for .FOOU.EDU",
but I'll bet even that traffic will kill the net, and you still run into the
problem of how do you change that single password without bringing the entire
net to a grinding halt.

>> So, in short, I'd say that the most important technical question to be asked
>> is how do you know that you can trust the public key you are given.
>
>This reduces to the question of how secure we can make a carefully
>chosen single example of a single encryption method: the directory's
>encryption function.

Nope, you can't do it with just one directory server.  You still need
something additional to provide trustability of the public key someone
hands you, and that something can not be just a simple
public-key-signed handshake, because any such handshake assumes you
already know the other guys' key.  There is no point in worrying about
security of encryption algorithms until you can solve the distribution
problem. 

>>--Don Alvarez,   boomer@space.mit.edu
>---Dan Bernstein, bernsten@phoenix.princeton.edu

----Don Alvarez,   boomer@space.mit.edu