In thinking more about Eric's proposal for a terminal program, I can see the value in putting in the hooks for stream encryption even if we don't implement it right away. That should be one of the points of this software, to have it be easily expandable. So we would want to make it so that a layer could be inserted just above the serial I/O layer which would do transparent encryption. The mechanism for creating the shared keys could be added later, perhaps. We are seeing a lot of different suggestions here, which is good at this point. Some of the issues: Overall functionality To keep our focus: we want something which will help the average computer user who has a PC or something similar at home be able to use encryption easily in sending and receiving email. The problem is that people send and receive mail in very many different ways. So we propose to provide a very flexible and extensible solution that can be adapted to many situations. This leads to the idea of a terminal program with built-in encryption, since most people can use a terminal program to get their mail. This would not be aimed at people running UUCP or similar fancy protocols on their home machines. They must be pretty sophisticated to get this stuff working. PGP and RIPEM already come with a bunch of scripts to let them be used in Unix and similar environments. (Maybe I'm mistaken, though, in thinking that good solutions already exist for these people. I don't know much about this mode of operation.) Build or Buy Do we roll our own or do we try to tap into an existing program? Among existing terminal programs, do we: try to provide add-ons to widely used commercial or shareware programs (for which we don't have source); try to convince the authors of these programs to make the changes we desire; or find such a program which has source available (e.g. kermit) and take that as our starting point? Target OS We have seen suggestions for DOS, Windows, Unix, and Linux (about which I know nothing). DOS and Windows are the biggest target market and the most likely to be used by the naive users we are trying to help, IMO. It would not be too hard to write for DOS but to isolate the OS dependencies so it could be easily moved to Unix (and perhaps Linux). But the DOS vs Windows decision is more fundamental. More generally, it is the command-line vs GUI decision. It's very hard to write code which is portable across these two approaches. I would lean towards the command line approach because it is easier to write portable code, in my experience (portable between DOS and Unix, say, is easier than portable between Windows, X, and Mac). But just fixing on Windows is another option. Serial Interface Focusing on DOS, apparently there are several ways of interfacing to the serial port. I know nothing about these. The main issues would be portability - does it require the user to have some third-party software, or to run on only a limited subset of PC clones - and efficiency - can we run at 9.6 or 14.4 Kbaud? What solutions accomplish both of these? And what if we went with Windows? Does that narrow our options? User Interface I still think this is one of the harder issues. How exactly can we make this easy to use? Can anyone suggest a non-magical (e.g. no mind-reading) but still ideal interface for encryption? I kind of liked Greg's suggestion of using the rollback buffer for decryption - when it sees an encrypted message go by it automatically decrypts it and offers it to the user to see. I'm not exactly sure what you do with it then, though. It would be helpful for me to hear more about how people read and send mail on their home computers, in some detail. If Mike Diehl got enough responses to his survey that would be good to hear about, too. Hal Finney 74076.1041@compuserve.com