Software infrastructure

-----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

>If you want the other software developers to pick up encryption then
>you had better put it into some kinda kit or TPU. 

Agreed.  The less hassle, the more use.

Buzzword alert.  What is "TPU"?  And who makes "Async Pro", and what
exactly does that do?

Eric