Software infrastructure

[nobody@shell.portal.com]

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