PGP on BBS

I have been mulling over the idea of a BBS door which allows users to
send PGP encrypted messages to other users using a system pubkey file. The
implimentation seems easy enough except for the problem of the secret key.
I don't see a way to do it without the sender having to transfer (at least
temporarily) his secret key to the host system. Obviously no one in his
right mind would ever consider doing such a thing. Has this kind of a
program been tried before? If so, how? If not, does anyone have any ideas?
Seems to me it would be a handy door for a BBS to have, but not at the
expense of compromised privacy...

David
david.brooks@cutting.hou.tx.us
<PGP 2.1 public key available by request>

 * Q-Blue v0.7 [NR] *                    
----
+---------------------------------------------------------------------+
| The Cutting Edge BBS (cutting.hou.tx.us)    A PCBoard 14.5a system  |
| Houston, Texas, USA    +1 713 466 1525          running uuPCB       |
+---------------------------------------------------------------------+

David Brooks writes:
>   I have been mulling over the idea of a BBS door which allows users to
>send PGP encrypted messages to other users using a system pubkey file. The

>I don't see a way to do it without the sender having to transfer (at least
>temporarily) his secret key to the host system. Obviously no one in his

Well, you could always allow the users to download the public key file
and do the encryption on their home machine, and then upload the mail file.

That way their secret key stays off the BBS...

/-----------------------------------\
| Karl L. Barrus                    |
| barrus@tree.egr.uh.edu (NeXTMail) |
| elee9sf@menudo.uh.edu             |
\-----------------------------------/

The scenario David Brooks outlines is extremely common: one host
computer providing information services to another computer which acts
as a terminal.  This may be a BBS, Compuserve, Lexis, or any number of
other services.  If there exists an implementable mechanism which does
not require trust of the host, then it should be implemented.

In the case of cryptography, this means that secret information should
not be transmitted to the host.  Hence all operations which use secret
information must be performed on the terminal computer.  These
operations include session key generation and signing of messages.

The solution is cooperative processing systems, where both the host
and the terminal cooperate to perform some task.  Unfortunately, there
is precious little software infrastructure to support such a
development.  Terminal programs on PC's are still for the most part
acting as dumb terminals, with the notable exception of file transfer
protocols such as zmodem.

I believe that cooperative communication software will be necessary
for widespread use of cryptography--not just pleasant, but a
precondition to large scale deployment.

Although this topic is not directly related to cryptology, it is
certainly appropriate for discussion on this list.  It is the
cypherpunk goal for widespread use of crypto by the masses, and the
exact nature of the infrastructure necessary for that task should be
debated, then implemented, then deployed.

Onward.

Eric

The solution is cooperative processing systems, where both the host
	 and the terminal cooperate to perform some task.  Unfortunately, there
	 is precious little software infrastructure to support such a
	 development.  Terminal programs on PC's are still for the most part
	 acting as dumb terminals, with the notable exception of file transfer
	 protocols such as zmodem.

What would the two systems be cooperating about?  I'm not sure to what
you are pointing.

	 Although this topic is not directly related to cryptology, it is
	 certainly appropriate for discussion on this list.  It is the
	 cypherpunk goal for widespread use of crypto by the masses, and the
	 exact nature of the infrastructure necessary for that task should be
	 debated, then implemented, then deployed.

I of course map these suggestions into Joule (the language I'm
developing).  Does that resemble what you're thinking of?

dean

I wrote:
>>The solution is cooperative processing systems, where both the host
>>and the terminal cooperate to perform some task.  

Dean asks:
>What would the two systems be cooperating about?  I'm not sure to what
>you are pointing.

Here are two basic examples:

1. Session key creation.  I regularly log in remotely to my account at
soda.  I'd like to have that modem link encrypted, with session keys
generated on the fly.  So I'll want to use some implementation of
Diffie-Hellman key exchange to make a session key.  The nature of this
protocol means that both my terminal program and my host have to do
calculations and exchange data.  Therefore I need software on my PC at
home and software on the host that work together.

2. Digital signatures.  I read and send my e-mail on the host.  When I
send PGP-encrypted mail, I have to compose the message on the PC,
encrypt it with a PGP command line, upload it to the host with zmodem,
and read it in to my mailer.  I'm certainly not going to put my secret
key on the host.  

What would be ideal is a cooperative protocol that initiated (in the
background, away from my main connection) a channel, sent just the
data to be signed (an IDEA key, for example), have my PC sign the data
and send it back.  This not only entails software on each end, but
also a line multiplexer so that the signing can take place on a
separate channel.  If it doesn't occur on a separate channel, then I
have to see it, probably move to the shell in order to start it
properly, and in general make it non-automatic.

Eric