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
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
participants (4)
-
david.brooks＠cutting.hou.tx.us -
Eric Hughes -
Karl L. Barrus -
tribble＠xanadu.com