D-H telnet protocol * Cheap secure phones

[pmetzger@shearson.com (Perry E. Metzger)]

>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