-----BEGIN PGP SIGNED MESSAGE----- Subject: Software infrastructure I like Eric's idea of a terminal program which can support encryption easily. Here are some thoughts. As Eric indicates, the issue is not so much building encryption into the program but rather of having _hooks_ by which extra functionality can be added. Encryption should be just one capability. Another might be to automatically drop into a stand-alone zmodem package like dsz or gsz so we don't have to re-implement zmodem ourselves. We had some related discussion on this last year when we were talking about the "crypto dongle". This was going to be a black box which would sit on the serial line between your PC and modem (or terminal and host computer) and would do encryption/decryption as the characters passed through it. Doing it in the terminal program, I could envision a hook which watched constantly for particular strings to be received from the host, like "-----BEGIN PGP MESSAGE-----". Several such watchdogs could be active at once. When one of them matches, it fires off a program. Or perhaps it just starts logging the incoming data to a file, and when it matches another string it fires a program. A simple scripting language could control these activities. The result would be that when you receive an encrypted message, you just list it out to your terminal and then, automatically, PGP fires up and asks you for your pass phrase (unless you SET it ahead of time in the PC's environment). It then displays the message for you. This simple model has several deficiencies. When I log into a Unix system, or Compuserve, or Portal's "Online" service, and read my mail, it is often shown to me a page at a time. This is so that I can read long messages more easily. Then after each message I can delete it, save it, reply to it, etc. If I do reply or if I want to create a new message it will drop me into a text editor to compose the message. The result is that the mail program you are running on the host computer may do some munging on the PGP message, like inserting "Press RETURN for next page" or perhaps some terminal control characters. These would have to be filtered out before PGP could run on the file, or you would have to be able to suppress them when you read this message. Also, assuming we could capture the message and run PGP on it automatically, the resulting decrypted message will have to be saved and given a file name. Then if the user wants to reply to it he is going to have to leave his terminal and run an editor. (At least, that's what I have to do now.) Plus, this only deals with the message-receiving problem, not the sending problem. I'm not sure what the solution is. Maybe the PC program needs to be more than a terminal program, and become more of a whole mail-processing program. Maybe you should just download your mail file en masse from the host to your PC, pre-process it to replace (in place) the incoming encrypted messages with plaintext versions (annotated to show validated signatures), then run a PC program which will display one message at a time, let you reply, save, etc. This way the decryptions are done before you even look at the mail file and incoming encrypted mail is treated on a first class basis (the same as other mail). Then for outgoing mail you'd like to be able to drop into a user-defined editor which is run with a command line causing his file to be saved to some temp file name. Then we can automatically encrypt the outgoing mail for him based on the destination, add a remailer chain if requested, etc. Then he gives a command and all his replies and new mail are uploaded and sent. This would be pretty tough to do since there are so many different ways of sending and receiving mail on host computers. This would again have to be a customizable part of the program, where we could provide modules to deal with the common cases of Unix running "mail", elm, mh, etc., and perhaps some of the commercial services. BBS's would ideally be handled as well. Hackers could contribute scripts for supporting their favorite mail system. I don't know anything about SLIP, or POP, or any other fancy ways of hooking a PC up to a workstation. I just use it as a terminal. Would these other protocols help solve the problems above, problems of how we marry an encryption program which must run on the PC with mail-handling programs which run on another computer? Hal Finney 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLAwkEagTA69YIUw3AQEuxQQAjeC/gwPHkLQZ0IladVRxiRdgARdE7ziu WWdmsHpaZ2tlq8wAXpSFbMpSZ3MS1U1TT/c/wB2DJOCuWkhs2y6WYoZiqrHz3hjA JyBSkpM1F3dYcZ8MchrjLZsur9KwXe0mIvM7VMu2Fdq+sMMgNwzEzqJoWhulAsnl weuBaeOjv7k= =zEUv -----END PGP SIGNATURE-----
Subject: Software infrastructure
...other good stuff deleted...I read mail at 2400B.
The result would be that when you receive an encrypted message, you just list it out to your terminal and then, automatically, PGP fires up and asks you for your pass phrase (unless you SET it ahead of time in the PC's environment). It then displays the message for you.
This simple model has several deficiencies. When I log into a Unix system, or Compuserve, or Portal's "Online" service, and read my mail, it is often shown to me a page at a time. This is so that I can read long messages more easily. Then after each message I can delete it, save it, reply to it, etc. If I do reply or if I want to create a new message it will drop me into a text editor to compose the message.
The result is that the mail program you are running on the host computer may do some munging on the PGP message, like inserting "Press RETURN for next page" or perhaps some terminal control characters. These would have to be filtered out before PGP could run on the file, or you would have to be able to suppress them when you read this message.
If we are talking about an off-line reader, this is solved by a trivial filter routine. If you want to do this on-line, well it might take time.
Also, assuming we could capture the message and run PGP on it automatically, the resulting decrypted message will have to be saved and given a file name. Then if the user wants to reply to it he is going to have to leave his terminal and run an editor. (At least, that's what I have to do now.)
Why save the plaintext? I keep it in cyphertext and decrypt it on demand. And when I want to reply, then I decrypt it, quote it and have the user edit that file, which will presumably be re-encrypted.
Plus, this only deals with the message-receiving problem, not the sending problem.
Actually, these are the same problems in different clothes.
I'm not sure what the solution is. Maybe the PC program needs to be more than a terminal program, and become more of a whole mail-processing program. Maybe you should just download your mail file en masse from the host to your PC, pre-process it to replace (in place) the incoming encrypted messages with plaintext versions (annotated to show validated signatures), then run a PC program which will display one message at a time, let you reply, save, etc. This way the decryptions are done before you even look at the mail file and incoming encrypted mail is treated on a first class basis (the same as other mail).
Then for outgoing mail you'd like to be able to drop into a user-defined editor which is run with a command line causing his file to be saved to some temp file name. Then we can automatically encrypt the outgoing mail for him based on the destination, add a remailer chain if requested, etc. Then he gives a command and all his replies and new mail are uploaded and sent.
These last 2 paragraphs describe almost exactly what my scripts do!
This would be pretty tough to do since there are so many different ways of sending and receiving mail on host computers. This would again have to be a customizable part of the program, where we could provide modules to deal with the common cases of Unix running "mail", elm, mh, etc., and perhaps some of the commercial services. BBS's would ideally be handled as well. Hackers could contribute scripts for supporting their favorite mail system.
I find that I need to be a bit more modular with my scripts so that I can call a different module depending on which type of system I'm on...Working on it at this moment. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl@triton.unm.edu | But, I was mistaken. |available| | mike.diehl@fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+
Let me clarify the discussion here about PC terminal software. There are two distinctions I'd like to make. The first distinction is between a terminal program and a mail/news reader. Terminal access is necessary so that all functions of the dialup service which are not mail/news can still be accessed. An integrated mail/news reader is desirable because this is a primary activity of many users. Ideally, you want both. The second distinction is between stream and file encryption.If you want to encrypt the underlying channel, you need a stream cipher and a D-H key exchange. If you want file encryption, you want a block cipher and public keys for communications. These two distinctions are correlated. The terminal nature of such software requires support for stream encryption. The mail nature of such software requires file encryption. PGP is a file encryptor, not a stream encryptor. You can't use PGP for the terminal line; you can you it for email.
As Eric indicates, the issue is not so much building encryption into the program but rather of having _hooks_ by which extra functionality can be added.
One useful discussion would be to examine just what hooks are desirable. The capability 'encryption' is too broad; one needs to specify just what variety and what purpose is desired. Re: dealing with mail software intended for humans.
The result is that the mail program you are running on the host computer may do some munging on the PGP message, like inserting "Press RETURN for next page" or perhaps some terminal control characters.
It is for exactly reasons like this that one of the hooks should be an ability to specify how one gets one's mail. For Unix, I would suggest POP, as Paul Ferguson has mentioned. For online services like compuserve, aol, etc., a separate protocol which spoofs their mail readers into sending you your mail en masse could be written. This also implies the existence of offline mail readers.
Plus, this only deals with the message-receiving problem, not the sending problem.
Trying to spoof a whole mail system on a terminal seems doomed. Offline readers are the way to go.
Then for outgoing mail you'd like to be able to drop into a user-defined editor which is run with a command line causing his file to be saved to some temp file name.
What editor you use is another hook. I use Desqview, and I love to be able to spoof Desqview into spoofing my editor (which is _always_ running) into editing my reply. So the hook has to be a bit more flexible that running an executable. Eric
If you want the other software developers to pick up encryption then you had better put it into some kinda kit or TPU. That is the easiest way to get those other people like Mustang Software to add hooks into their software. If you distributed some kind of TPU to add onto Async Pro then you just made it really easy to add encryption onto a couple of BBS packages. If you were to make a TPU I think you should have the code to handle file encryption and stream encryption built into it. For Async Pro you could just make up a send_cipher function that encrypts the data then calls Async Pro's serial send function. I also think it would be better to come up with some freeware so people don't have to go buy Async Pro, but that would be a good quick cipher engine for PC serial IO if you just added onto Async Pro without worrying about the serial routines for the moment also. d. saint
participants (4)
-
Eric Hughes -
J. Michael Diehl -
mmidboe＠cs.uah.edu -
nobody＠soda.berkeley.edu