From: henry strickland <strick@osc.com>
Date: Fri, 4 Jun 93 09:36:24 PDT
To: hughes@soda.berkeley.edu (Eric Hughes)
Subject: Re: Term software develo
In-Reply-To: <9306040538.AA19367@soda.berkeley.edu>
Message-ID: <9306041644.AA19277@osc.com>
MIME-Version: 1.0
Content-Type: text/plain


With the idea of building a Macintosh terminal emulator with an
encrypted transport stream, I've been looking over the sources to
"info-mac/terminal-22.hqx" from "sumex-aim.stanford.edu".

Realizing that it is not most people's terminal emulator of choice,
and that authors may not want to give up their terminal source code,
I've been thinking about what kind of an API could be negotiated
between terminal-program authors and encryption-mechanism authors.

Suppose a terminal program looks for resources (using macintosh-like
terminology for a moment) of some type 'Encr', and load them.
It expects to find subroutines there, that the 
cypherpunk can add to any conforming terminal emulator.
Something like this:

  resource #1:  function initialize() -- grab resources
  resource #2:	function set_key(char key[8])
  resource #3:  function encrypt(long block_no, char block[8]) 
  resource #4:  function decrypt(long block_no, char block[8])
  resource #5:  function finalize() -- shutdown, release resources

This would support experimentation without necessarily having 
the source code to a terminal emulator.  ( If PC and MAC people
took the "all software source must be free" approach that we do
in the UNIX world, this would be less a problem.... )


Obvoius Problems not addressed by these 5 functions:

	-- does not address a linklevel standard for 
	   packetizing the stream and numbering the datagrams.
	   I assume this sort of transport is necessary.
	   (It would be amusing to see a demonstration that
	   it is not!)  It's actually a nice side-effect; I'm sick
	   of transmission errors, even when I'm in supposedly
	   error-free modes.

	-- does not talk about key exchange.

	-- does not talk about crypto-strong authentication 
	   of the user to the system you're dialing into.

It does assume 8-byte keys and 8-byte cypherblocks; 
but that's easy to fix. 

The approach I'm NOT considering at the moment is writing
a new communications device which is a wrapper around the
exisiting comm port, but that is a MUCH better approach.  
But I'm not up to that level in my mac-programming yet, and
I was looking for somthing I thought I could finish.




Anyway, my essential point is, let's publish and compare our 
link-level standards and our encryption models, so that we can
debate them, and end up with a set of plug-compatible tools for
different platforms, with hooks for substituting mechanisms.


						strick





p.s.  	if anyone has summaires/comparisons/case studies of different
	"guaranteed stream" link protocols (kermit, XMODEM, YMODEM,
	ZMODEM, TCP), I'd be interested.   Code would be even better.
	(however, trying to reappropriate TCP/SLIP/HeaderPrediction 
	seems to massive an undertaking; I'd like something simpler.)  
	This is one wheel I hate to reinvent....