Coupled programs and security by obfuscation
**** Pat Farrel <pfarrell@cs.gmu.edu> writes
I expect that current terminal/menu based BBSes will disapear once folks realize how much better easier, faster, and all around better programs that use computers as computers work.
I hope not... At least not until the BBS operators and writers agree on some standardized API so people like me and other third parties can write PC based interfaces in a language of our choice. The problem with current "coupled systems" (for example the Coconet BBS software) is that they all rely on proprietary interface programs on the PC. If I communicate with 10 BBS systems (large or small), I must have 10 different communications programs... No thanks... Also keep in mind that much of the value of these systems comes from their availability to the widest possible audience. There are people in many parts of the world who still have nothing better then 1970's style glass tty's and even paper-output type terminals! ****** Back on the issue of privacy and anonymity, I don't understand the lure of all these schemes for hiding mail paths, etc. If encrypted messages pass through one aliaser, and get decrypted (and aliased again) on another machine, you are protected. The machine that knows who you are can't read your material, and the machine that can read you doesn't know who you are. Any further obfuscation adds little (IMHO) to your security. Revelation of your identity (in either case) depends on collusion between system administrators on the different hosts. True this might be even less likely where 3 or more hosts are involved, but how much less so? If some agency is powerful enough to force two systems in different parts of the world (and the net) to reveal what they know about you, the chances are they can force three or four, etc. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr@netcom.com 70371.255@compuserve.com
Matthew Rapaport writes:
At least not until the BBS operators and writers agree on some standardized API so people like me and other third parties can write PC based interfaces in a language of our choice.
This is exactly the goal. For example, zmodem has a widespread deployment and a public specification. What needs to happen for cryptography is the development of such protocols for key exchange, signatures, and other cryptographic entities. Eric
Matthew Rapaport writes:
[...] I don't understand the lure of all these schemes for hiding mail paths, etc.
The disambiguating question is "What is the capability of your opponent?" Some opponents have only access to their own machine as users, and some have access as root. Others have access to all traffic on the local network and can thus see all mail entering and leaving a system. Others, we might assume, have access to all traffic on any non-local network. The rule is the following. If it's cheap enough to defend against even the strongest opponent, deploy it. Cryptography, with its presumably exponential difference between the costs of defense (encryption) and offense (cryptanalysis), allows for economical solutions against even the largest of opponents. Cryptography is a greater leveler than the Colt .45 revolver. Eric
Eric Hughes (hughes@soda.berkeley.edu) wrote: : This is exactly the goal. For example, zmodem has a widespread : deployment and a public specification. What needs to happen for : cryptography is the development of such protocols for key exchange, : signatures, and other cryptographic entities. I thought that was the point of PEM? Why not integrate the PGP encryption protocol into the PEM structure? - Mitra
Eric Hughes (hughes@soda.berkeley.edu) wrote: : What needs to happen for : cryptography is the development of such protocols for key exchange, : signatures, and other cryptographic entities.
Mitra writes:
I thought that was the point of PEM? Why not integrate the PGP encryption protocol into the PEM structure?
I am talking about interactive protocols. To generate a session key for communication with some remote host will require both parties to cooperate. PEM is a standard for "privacy enchanced" electronic email formats and encryption methods. PEM is not a standard for interacting protocols. Eric
participants (3)
-
Eric Hughes -
Mitra -
mjr＠netcom.com