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