Re: Defeating MITM with Eric's Secure Phone

-----BEGIN PGP SIGNED MESSAGE-----

My apologies if this has already been discussed, but wouldn't this be
a straightforward solution?

Alice and Bob use PGP as a secure, identified channel to exchange a
random 6 digit hex number.  For example, 0xC926D0.

When they establish their Comsec connection, they read 0x5F92E4 off
their units.

Alice takes the digits C, 9, and 2, and adds them mod 16 to 5, F, and
9 to get the digits 1, 8, and B, which she reads to Bob who confirms
them.  (Adding just the digits instead of larger numbers means that
Alice and Bob can do the computation in their heads.)

Bob takes the digits 6, D, and 0 and adds them mod 16 to the digits 2,
E, and 4 to get 8, B, and 4.  Bob reads them to Alice who confirms
them.

Any flaws?

Monty Cantsin
Editor in Chief
Smile Magazine
http://www.neoism.org/squares/smile_index.html
http://www.neoism.org/squares/cantsin_10.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBND2EZ5aWtjSmRH/5AQGBnQf/QRMe/66ge+M/zHzzrZ7zc3g9wFKESsjA
alzeGfUulzp+18JyUy1RHNOtM+4bXZUaiYAN7FnxKkAkY+IzW5m7nDHMnC18e+bD
IZpO626Ze+pumokhXVTYW0JHWF4OfCol4qmYNSTjM+n4RO0DcmecOuQYuwnscJvb
808rsuin09dhY3UV5uyDWrCwuATIRjwSRTewBinuTGZo/QtMurXJlPc45WtF07oC
9Tg3ebnnq0NtbxWmsX7WT/tjFHoniS5sPoBusrlZT+1z+PT0SzqtSR1JmWKGVQQC
xubaghabXvNj9nZZPsEGCG4rMbJw8Qtoh9J6I+aQJ0TVK4hHuanJXw==
=Ooh/
-----END PGP SIGNATURE-----

Monty Cantsin writes:
> My apologies if this has already been discussed, but wouldn't this be
> a straightforward solution?

John Kelsey described the same system.

[adding hex passphrase digits exchanged via PGP to display digits]

> Any flaws?

See my other recent post in this thread... I think it doesn't work
because Mallet can recover the passphrase.  You must remember that
when Mallet is actively doing a MITM attack he knows the digits on the
display of each party.  With that info he can recover the passphrase
by subtracting.  Then he can give Alice the correct checksum for the
link A<->M and Bob the correct checksum for the link M<->B.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 11:31 PM 10/9/97 -0400, an Anonymous Monty Cantsin wrote:
>My apologies if this has already been discussed, but wouldn't this be
>a straightforward solution?

Yes, your PGP solution will work.  Information-theoretically speaking, it's
a simple XOR, and is as secure as the random number generator used and the
PGP systems used to exchange your secret key.

However, so will a thousand other schemes that use PGP, or any other
"out-of-band" form of authentication.  At this point you realize that you
are using PGP for authentication, not the "Secure Phone".  Our discussion
so far has been ways of authenticating the connection WITHOUT external
references.  No pre-exchanged public keys, no pre-arranged passwords or
secrets or any of that.  (They even disallowed me a trip to ask a trusted
authorizer!)

To restate the problem in its current form:  using the secure phone
channel, (and only the secure phone channel) can we "prove" that we are
connecting only two endpoints, and that there is no man-in-the-middle
between the voices that are speaking to each other?  Remember that Mallory
(the man in the middle) has full knowledge of the protocol and of the
public keys belonging to both parties.  He can even spoof the voices.

The latest candidates for solutions have been "have the users identify this
flaw in the audio" which is probably as good as we can hope for on an
unauthenticated conversation.

As it is, Eric's current solution to have each party simply read their half
of the hash.  Real-time impersonating the audio to the point where you can
fool a careful human is already putting a great deal of exposure risk on
Mallory.

My bottom line:  I would trust Eric's current phone to all but eliminate
the MITM, and with external authentication I wouldn't have any problems at
all.

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                                               |
+--------------------------------------------------------------------+