RE: Term software develo

Eric Hughes says:

> FOSSIL is . . . the only abstraction for serial communications 
the PC has . . .

There are at least 7 versions of INT 14. Then there's 
Ungerman-Bass's old INT 6B as well as two flavors of its 
successor, NASI/NCSI. There are also many variants of COMx 
device drivers. These are all serial line abstractions for the 
PC. There are others.

FOSSIL may be popular on BBSs, but NASI/NCSI is number one in 
the market. The oldest version of INT 14 is number two.

Who was it said "The nice thing about standards is that there 
are so many to choose from"? :-)

Doug

>FOSSIL may be popular on BBSs, but NASI/NCSI is number one in 
>the market. The oldest version of INT 14 is number two.

What are NASI/NCSI?  Does it cost to use them?  Is source available?

Eric

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