Eric Hughes speaks: EH> The solution is cooperative processing systems, where both the host EH> and the terminal cooperate to perform some task. Unfortunately, there EH> is precious little software infrastructure to support such a EH> development. Terminal programs on PC's are still for the most part EH> acting as dumb terminals, with the notable exception of file transfer EH> protocols such as zmodem. EH> I believe that cooperative communication software will be necessary EH> for widespread use of cryptography--not just pleasant, but a EH> precondition to large scale deployment. You've hit the nail on the head here, Eric. If public key encryption is REALLY going to be for the masses, we are going to need something like this... But it seems I'm going to have to code the damned thing myself, eh? Anyone want to help? EH> Onward. Indeed! David david.brooks@cutting.hou.tx.us * Q-Blue v0.7 [NR] * ---- +---------------------------------------------------------------------+ | The Cutting Edge BBS (cutting.hou.tx.us) A PCBoard 14.5a system | | Houston, Texas, USA +1 713 466 1525 running uuPCB | +---------------------------------------------------------------------+
What you are all talking about here is a solved problem. Many such network protocols exist. SLIP is probably the best example. If you use SLIP to connect to the BBS instead of a dumb terminal connection, you get a real network link which supports multiple connections to multiple destinations. And free SLIP implementations exist. The author of one of the most popular is on this list, in fact. Of course, this requires that your "terminal" be somewhat intelligent, but even a lowly 8088 PC running DOS can run SLIP. If you do this, all you need is a BBS which supports network services, instead of the current menu-based sort of systems we have now. If you want to encrypt, you do so locally. In fact, you'd probably do almost everything locally. Marc
participants (2)
-
david.brooks＠cutting.hou.tx.us -
Marc Horowitz