Keystone

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