Re: adding D-H key exchange to PC software gnu@cygnus.com writes:

Given a working Unix implementation, it would be relatively easy to add to the terminal program, if source code for any decent terminal programs was available.

But source code is not available. The trouble is that all the decent terminal programs for PC's are shareware or commercial (or were originally shareware and have become commercial). I too would like to know of any source-available PC terminal programs, but I suspect there are none because of the prevailing shareware culture. Re: getting an author to license D-H key exchange The reason this will not happen is not the bootstrapping problem (chicken/egg), but that there is no perceived value to an encrypted link. The sysop is already has access to everything on the dedicated machine and may even have a policy of scanning all messages. External hackers can't really get in because shell access isn't really done remotely. The only ones you are protecting against are people with a hard tap on the phone line itself. For most people, this is not a concern. Since there's no perceived value and since all the software would require license from RSADSI, it won't happen that way. Re: using a protocol layer avalon@coombs.anu.edu.au writes:

Rather than rewrite the terminal progs, why not rewrite the BIOS level drivers and such ? (if its possible).

That's not possible either. Most terminal programs write directly to the hardware. This is single-tasking, standardized hardware, remember, and the original BIOS interface for the serial port was totally unusable. Some communications programs use FOSSIL drivers, but many (if not most) terminal programs don't support it. (FOSSIL is a BIOS-level serial port interface description which could hooked into or rewritten to support a protocol.) Look, I wish all this stuff were in use. Everyone should encrypt all their communications links as a matter of policy. (That includes voice, and if you thought the PC terminal program bootstrapping was difficult ...) Let's move incrementally, though. If we can get people to at least encrypt all of their e-mail, that will be an excellent start. One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? Eric