Ah. A small PGP subset. You hadn't mentioned this. When you said you weren't requiring the user to run PGP, I assumed key generation must occur on the board. As for your fatal flaw I hadn't spotted, I had spotted it, and the location of the private key was the critical point. If the key is on the BBS, the message goes out in the clear. Look, it boils down to this. If the message traffic to the BBS is to be encrypted, then the user has to generate a key on his own machine and decrypt it on his own machine. There's no way around that. But the user interface problem can be solved. Just make a bunch of .com files which do nothing but spawn pgp by invoking the correct arguments. Very simple; a few lines of C is all. Even the PGPPATH can be set before the spawn. It's an easy encapsulation. It will run a bit slower for load time, but not appreciably. And you won't have to recompile PGP from the distributed executables. Eric
We have a small project cooking, to use Diffie-Hellman key exchange to choose a random key to encrypt Internet connections (telnet, rlogin, ftp, smtp). This same protocol can also be used over an ordinary modem connection between a user's PC and a BBS, preventing eavesdropping or wiretapping of that phone call. It would also be able to protect phone calls between a PC and a Unix timesharing system, regardless of what networks lie in between, if we wrote a simple login program that handled the modem protocol. (It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.) (I suggest that the initial Diffie-Hellman handshake all be done in ASCII encoding, no matter what the medium, so that the same protocol can be used on all media, binary-transparent or not.) This scheme would require support in the BBS and in the user's PC terminal program. 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. This is where Unix shows a real advantage, since you can get free source for just about program, while "free" PC programs means free binaries. If anyone knows of a reasonably popular PC terminal emulator for which source code is freely available and distributable, let us know. (Or, if anyone knows the author of a popular commercial PC terminal emulator program, tell the author that they could consider licensing Diffie-Hellman from RSA for commercial use and adding it to their proprietary terminal program. They're unlikely to do so, since it costs money, unless some very popular BBS's can also be upgraded to do it -- standard commercial chicken/egg problem which free source code solves.) On the BBS side, I've heard the idea of freeing the Fido source code as copylefted code. That would make it easy to add things like login session encryption for the modem users. John Gilmore
..
real advantage, since you can get free source for just about program, while "free" PC programs means free binaries. If anyone knows of a reasonably popular PC terminal emulator for which source code is freely available and distributable, let us know. PC Kermit, of course. The best vt100 emulator around, last I used them heavily.
sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@world.std.com CIS 76244.210@compuserve.com OO R&D Source Dist. By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342 GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together
From: gnu@cygnus.com
We have a small project cooking, to use Diffie-Hellman key exchange to choose a random key to encrypt Internet connections (telnet, rlogin, ftp, smtp). This same protocol can also be used over an ordinary modem connection between a user's PC and a BBS, preventing eavesdropping or wiretapping of that phone call. It would also be able to protect phone calls between a PC and a Unix timesharing system, regardless of what networks lie in between, if we wrote a simple login program that handled the modem protocol. (It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.)
I would suggest that it be done during phase one. Spoofing attacks are very important things to guard against, and thanks to PGP there is a handy dandy set of code out there to steal from to provide for public key based authentication of the link. Indeed, I would go further and suggest that the protocol be designed so that it does not reveal the entities forming the link to outsiders (unless one end should intentionally advertise who it is, the assumption should be that both ends know who the other end is a priori). There is also a very good implementation of the IDEA cypher in PGP, which should run well as the conventional cypher for the link (although I would suggest having the protocol negotiate the cypher just in case IDEA gets replaced later on). I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable. The presense of code in the public domain to handle secure encrypted links could be easily dropped right in to this application.
(I suggest that the initial Diffie-Hellman handshake all be done in ASCII encoding, no matter what the medium, so that the same protocol can be used on all media, binary-transparent or not.)
I agree that this should be a negotiated option in the protocol (prehaps with some sort of test done at the beginning of the link for line transparency), but I'm not sure it should be mandatory as that eighth bit get significant at times.
If anyone knows of a reasonably popular PC terminal emulator for which source code is freely available and distributable, let us know.
Kermit is the obvious choice. Perry
I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable. The presense of code in the public domain to handle secure encrypted links could be easily dropped right in to this application.
I've had much the same idea. There are a lot of people out there with PCs equipped with Soundblasters and V.32 modems. I can't think of a better way to fight back against that ridiculous FBI Telephone legislation. -- Bill O'Hanlon Network Systems Corporation bill@network.com
From: bill@anubis.network.com (Bill O'Hanlon)
I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable. The presense of code in the public domain to handle secure encrypted links could be easily dropped right in to this application.
I've had much the same idea. There are a lot of people out there with PCs equipped with Soundblasters and V.32 modems.
I can't think of a better way to fight back against that ridiculous FBI Telephone legislation.
Its not quite that simple. The amount of computing horsepower needed to do a good digitized voice compression algorithm like CELP is way beyond what a PC can do without a DSP. However, having most of the link layer encryption stuff out of the way will make the rest of the work much easier. Perry
(It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.)
I would suggest that it be done during phase one. Spoofing attacks are very important things to guard against, ...
Fine, Perry. You do it. I want to get some "easy" protection out there now. Easy often turns out to be six months of work all by itself.
suggest that the protocol be designed so that it does not reveal the entities forming the link to outsiders (unless one end should intentionally advertise who it is...
This is the intent. The D-H protocol will not reveal any identifying information, and the rest of what is transacted will be protected under the secret key produced by the D-H protocol.
I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable.
There's a "CELP" standard for voice encoding which you can get from the Feds. They used it as an upgrade in STU-III secure phones. It's Federal Standard 1016. It encodes voice at 4800 bits per second with better quality than any known algorithm under 16,000 bits per second (so says the paper on it). If you give it 16 kbits/sec, it is "toll quality". You can get a free copy of the standard, a "technical information bulletin 92-1" entitled "Details to Assist in Implementation of Fed Standard 1016 CELP", and four floppies full of C and Fortran software that implements it, plus test cases, by requesting it from: Office of the Manager National Communications System Attn: NT 701 S. Court House Road Arlington, VA 22204 +1 703 692 2124 Note that this C and Fortran code doesn't run in realtime on workstations; it requires a DSP. But as the "Implementation Details" paper says: "A high-quality, low power, small-sized voice processor can be constructed for under $200 parts cost in small quantities by adding to one of these [TMS320C31, DSP56001] DSP chips: ROM, 16k words of SRAM, and a Texas Instruments TLC32044 A/D and D/A with filters chip."
From: gnu@toad.com
(It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.)
I would suggest that it be done during phase one. Spoofing attacks are very important things to guard against, ...
Fine, Perry. You do it. I want to get some "easy" protection out there now. Easy often turns out to be six months of work all by itself.
Why should "hard" be that much more difficult? Looks like an extra few days worth of work if you pull all the public key code from PGP. Admittedly, this would be a big project if one couldn't steal existinc dode, but remember, PGP is copyleft. This whole project is a humungous patent violation anyway, so there is no good reason for not stealing code from PGP. Phil's code is bloody good. Anyway, the "easy" protection is probably the "hardest" part. Getting the encrypted link and drivers running properly is the big deal -- thats the code that will take all the time. Its likely marginal cost to design the protocol "right" from the beginning to make it easy to plug in verification later, and being able to use existing public key code to implement it likely removes most of the sting. All you have to do in order to "fix" things is have both sides public key encrypt their D-H exchanges, and suddenly, you have verification of identity.
suggest that the protocol be designed so that it does not reveal the entities forming the link to outsiders (unless one end should intentionally advertise who it is...
This is the intent. The D-H protocol will not reveal any identifying information, and the rest of what is transacted will be protected under the secret key produced by the D-H protocol.
Ah, but if you want to add in a verification layer, you have to be careful to make sure that you don't reveal too much information in doing the verification.
I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable.
There's a "CELP" standard for voice encoding which you can get from the Feds.
Well aware of it; I've got sample source code for CELP and all the rest. However, having a standardized bunch of software for encrypting the link will mean that I have that much less to worry about. Perry
Why should "hard" be that much more difficult? Looks like an extra few days worth of work if you pull all the public key code from PGP.
The project as I plan it, would require no administration on the part of users. Install and forget. If you add authentication, then end-users have keys to deal with, on an ongoing basis. As I said before, you're free to take what I come up with and add authentication. But stop berating me in public for doing something to further the use of cryptography.
This whole project is a humungous patent violation anyway, so there is no good reason for not stealing code from PGP.
You have made two bad assumptions here. I do not intend to violate any patents, nor do I intend to steal code from PGP. I'll be glad to talk in private about what is happening, but it is not ready for public discussion yet.
All you have to do in order to "fix" things is have both sides public key encrypt their D-H exchanges, and suddenly, you have verification of identity.
This is not true. I have a preprint of a paper by Whit Diffie that explains how to weave D-H and RSA together so that you can't accept the authentication but be spoofed on the key exchange, or vice verse. It starts with a simple protocol as described above. Known attacks are explained and the protocol is modified to deal with them. The result is now in use in commercial products (secure phones). It's not as simple as it looks. John Gilmore
From: gnu@cygnus.com
As I said before, you're free to take what I come up with and add authentication. But stop berating me in public for doing something to further the use of cryptography.
I'm not berating. I'm just suggesting. I understand your reasoning about not wanting users to need to do any administration, and I also understand your desire to do something good for the crypto community. I will not argue that its a bad thing. The only provisio I make is that it is SO easy to spoof exponential key exchange that I'd argue that providing authentication is crucial if people aren't going to be lulled into a false sense of security. Perry
participants (6)
-
bill＠anubis.network.com -
Eric Hughes -
gnu -
gnu＠cygnus.com -
pmetzger＠shearson.com -
sdw＠meaddata.com