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 | +--------------------------------------------------------------------+
participants (3)
-
Adam Back -
Anonymous -
John Deters