1997-10-02 - Re: Secure phone

Header Data

From: John Deters <jad@dsddhc.com>
To: “James A. Donald” <jamesd@echeque.com>
Message Hash: febd3a18a0c7ccffd039e7161f3d355372d649c5fdfb6295137f2e3f97c29260
Message ID: <3.0.3.32.19971002155954.00bfc7e0@labg30>
Reply To: <199710021621.JAA26807@proxy4.ba.best.com>
UTC Datetime: 1997-10-02 21:20:26 UTC
Raw Date: Fri, 3 Oct 1997 05:20:26 +0800

Raw message

From: John Deters <jad@dsddhc.com>
Date: Fri, 3 Oct 1997 05:20:26 +0800
To: "James A. Donald" <jamesd@echeque.com>
Subject: Re: Secure phone
In-Reply-To: <199710021621.JAA26807@proxy4.ba.best.com>
Message-ID: <3.0.3.32.19971002155954.00bfc7e0@labg30>
MIME-Version: 1.0
Content-Type: text/plain



At 09:21 AM 10/2/97 -0700, you wrote:
>At 11:13 PM 10/1/97 -0700, Lucky Green wrote:
>> Bad idea. You don't want people to have to look up keys to use your device.
>> Some people may not want to be listed in the phone book. Not to mention
>> that a PKI adds an additional and unnecessary layer of complexity. Just use
>> DH and have the parties each read half of a hash of the public
>> exponentials. No keys to store, no keys to remember, no keys to compromise.
>
>Trouble is this exposes the system to the man-in-the-middle attack.  Perhaps
>you could take advantage of the real time nature of the system to prevent
>man in the middle, by constructing a protocol such that man in the middle
>will invariably time out during the connection setup, or produce an
>audible lag problem in speech.

The MITM attack is thwarted by Lucky's note:
>> DH and have the parties each read half of a hash of the public
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> exponentials. No keys to store, no keys to remember, no keys to compromise.
   ^^^^^^^^^^^^^

Each party reads off a series of digits displayed on their screen.  Out
loud.  To each other.  Over the secure phone.

The MITM attacker can't duplicate the hash on both ends, because a hash of
the public keys used to make the connection are different between the
MITM's public key and the real public keys.

Here's a secure conversation (assume for the moment that the addition below
represents a strong hash):

Alice <-------------------------------------> Bob
PK=1234                                       PK=5678
1234+5678=6912                                5678+1234=6912
Alice reads 69 over the phone, and Bob reads 12 back to her.
Alice and Bob proceed to have a private conversation.

Now, since Mallory has to create a PK, he cannot just duplicate
Alice's 1234, because he'd also need the private key to decrypt the
conversation.  Likewise, he cannot duplicate Bob's 5678.  He has to
generate his own PKs in an attempt to fool Bob & Alice.

Alice <-----> Mallory <-> Mallory <---------> Bob
PK=1234       PK=1111     PK=2222             PK=5678
1234+1111=2345                                5678+2222=7900
Alice reads "23" over the phone, and Bob reads "00" back.
Since Alice's hash function said she should hear "45" back from
Bob, and Bob's screen said he should have heard "79" from Alice,
Alice and Bob decide to talk about the weather, and how pretty 
the trees are in certain cities.

Mallory could try to thwart this by impersonating Bob's voice to
Alice, saying "45", and Alice's voice to Bob, saying "79"
(Mallory does, of course, know these numbers), but if Bob & Alice
know each other, this probably won't work too well.  Mallory would
have to be able to cut into the conversation real-time, undetected.

Now, of course, Mallory could hire Anna & Barry to pull the whole
impersonation thing off, so that for the entire conversation Alice
talks to Barry and Anna talks to Bob, each thinking that they're
really talking to the other, but that's also fraught with risk.
I'm sure they could pull it off on TV, though  :-)

So, it'd go full circle back to pass phrases again.
"I hear the cherry trees are lovely in Washington D.C."
"I wouldn't know, I've never visited Washington in the spring."
"I agree, the weather is usually too wet."

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+






Thread