John Kelsey writes:

Adam Back writes: [computationally infeasible jobs for MITMs] I prefer to work on the more immediately useful problem: How can I secure my use of the (very nicely done) Comsec secure phones using existing infrastructure? I am concerned with the MITM voice impersonation attack, since that's the easiest attack on the system.

We were discussing this problem before turning to talking about automated methods. I think Eric Blossom suggested this earlier on:

1. Exchange PGP-encrypted e-mail establishing a set of sixteen different words, labeled for 0..f in each direction. Thus:

0. Dilbert 1. Alpha 2. Cable 3. Swordsman ... f. Marxist

Now, the checksum reading is very hard to spoof. Suppose I get 0x33f. I say ``My checksum is Swordsman Swordsman Marxist, or 33f.''

It seems like a good solution. An interesting question might be how many times can you use the same table without starting to leak values. Perhaps it doesn't matter that much because the MITM can't exactly use brute force on the problem otherwise you will know he's there. He has to act non-passively to extract information. (Presuming the protocol exchanges part of the information hashed for the challenge is encrypted with the negotiated key).

Now, the problem with this is that it's too cumbersome.

What would be nice would be able to have information on one sheet of paper which you could continue to use for lots of communications, without need for calculator, or computer, or more emailed tables.

The simplest way to do this seems to be to just exchange a six-digit hex value as a one-time password for a given secure phone call. This is done using PGP or some other mail encryption package, and can legitimately be used to exchange a long list of one-time passwords at once. Then, use Windows' calculator application to add your one-time password to the checksum. Thus:

1. I pull up Alice's latest encrypted e-mail, and get today's phone password.

2. I open the Windows calculator, set it to View/Scientific and hex mode, and type in the password (a six-digit hex number) and ``+.''

3. I call Alice, say hello, and push the ``SECURE'' button.

4. I type the six digit hex checksum into my calculator.

5. I read the first three digits of the result to her. She reads the next three to me.

I considered this approach (XOR and + function) earlier in this thread. I don't think it works because the functions are commutative. (Unless I'm missing some aspect of the system, perhaps the interlock... it's a while since I've read the protocols.) Here's why I think it doesn't work: We have Alice, Mallet and Bob. Alice & Bob exchange via email password 123456. The displayed digits of the hash of Alice/Mallet's DH parameters are: 222222. The displayed digits of Mallet/Bob's DH parameters are: 333333. Alice computes 123456 + 222222 = 345678; Alice says to Mallet: "345" Bob computes 123546 + 333333 = 456789; Bob says to Mallet: "789" Mallet recovers the first 3 digits of the passphrase from what Alice said: 345 - 222 = 123 Mallet recovers the last 3 digits of the passphrase from what Bob said: 789 - 333 = 456 Mallet has recovered the passphrase and can now spoof Alice to Bob and Bob to Alice, he says: 456+222 = 678 to Alice, and 456+333 = 789 to Bob. Same story with XOR, only it's harder to compute. I think you need an encryption function. It depends on how many times you wanted to re-use the passphrase. The "encryption" function could be very weak for one use. For lots of uses you'd need a real encryption function. Problem is encryption functions aren't typically very easy to perform as mental arithmetic exercises; and non-programmable calculators don't help much. The table solution gets around this problem nicely, because it is a secure way of using a one time password. Possibly a relatively secure way of re-using that password even, if mallet has to become active to obtain information, and gets detected on occasions when he doesn't yet have sufficient information. 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

Adam Back wrote:

John Kelsey writes:

...

Adam Back writes: [computationally infeasible jobs for MITMs] I prefer to work on the more immediately useful problem: How can I secure my use of the (very nicely done) Comsec secure phones using existing infrastructure? I am concerned with the MITM voice impersonation attack, since that's the easiest attack on the system.

We were discussing this problem before turning to talking about automated methods. I think Eric Blossom suggested this earlier on:

...

1. Exchange PGP-encrypted e-mail establishing a set of sixteen different words, labeled for 0..f in each direction.

It seems like a good solution. An interesting question might be how many times can you use the same table without starting to leak values. Perhaps it doesn't matter that much because the MITM can't exactly use brute force on the problem otherwise you will know he's there. He has to act non-passively to extract information. (Presuming the protocol exchanges part of the information hashed for the challenge is encrypted with the negotiated key).

I think you need an encryption function. It depends on how many times you wanted to re-use the passphrase. The "encryption" function could be very weak for one use. For lots of uses you'd need a real encryption function. Problem is encryption functions aren't typically very easy to perform as mental arithmetic exercises; and non-programmable calculators don't help much.

Plus - A table can be based on a previously agreed upon one-time pad, such as the old-school spook classic, first three words, second column, page 3, New York Times. PlusPlus - On the InformEnergy Highway, this method can be further obscured by use of data on an obscure website, text or source, binary or hex, etc. The point being, that one can use complex or obscure methodologies to obtain the one-time pad table of the day, which can be simple enough to calculate on-the-fly in one's head. there Are Some Similar metHOds peopLe can useE which can even be used by children, such as myself. Kill Flags - When WE' RElying on FeatUres of suCh Kinds, Everyone shoulD be using prearranged kill flags to signal danger. Keep in mind that I may just be telling you these things because I am a cop and trying to gain your confidence. OTOH, how many cops have a: Human Gus-Peter