# What are the weaknesses of this message exchange protocol?

Here is a protocol for a key exchange:

1. Bob encrypts a message $m$ with his key $K_B$: $m_1 = E_{K_B}(m)$.
2. Bob send the result $m_1$ to you.
3. Alice encrypts my encrypted above message with her own key: $m_2 = E_{K_A}(m_1)$.
4. Alice sends her encrypted message $m_2$ back to Bob.
5. Bob decrypts this message with his key: $m_3 = D_{K_B}(m_2)$.
6. Bob sends $m_3$ to Alice.
7. Alice decrypts this with her key: $m_4 = D_{K_A}(m_3)$.

You can now read my original decrypted cipher text and we didn't need to exchange keys. A 'man in the middle' attack will not work if the algorithm is not a simple XOR-ing of plain text and key. The cipher used in this example has a complex, commutative algorithm.

Here is an example:

• starting with notepad text file containing one character, an m.
• bob's encryption key is an E.
• alice's encryption key is an x'.
• m is hex 6d 01101101.
• Â is hex c2 11000010 which is 'm' encrypted by bob and then sent to alice.
• $ is hex 24 00100100 is Alice's encryption of Â which bob decrypts to Ï and sends to alice. • Ï is hex CF 11001111 which alice decrypts to 'm' with her key. • m is Alice's decrypt result. MITM sees Â, alice's message before her encryption. MITM sees $, Alice's message after her encryption. MITM XORs Â and $ 11000010 Â 00100100$
-----------
11100110 æ


So, MITM's XOR result is the symbol æ (E6 in hex). If MITM attack would have worked, he would have found x (hex 78, binary 01111000) which is first letter of Alice's key.

This protocol seems much simpler than things like a Diffie-Hellman key exchange.

To what kind of attacks would it be vulnerable?

-
I edited the first part (where you describe the protocol), to make it more readable. I don't know what to do with the second part, as I don't understand it. Are you describing the "complex commutative algorithm" there, or are you trying to argue that it is immune to a MitM-attack? –  Paŭlo Ebermann Sep 7 '13 at 14:04
All I'm saying is this seems a simpler key exchange than PGP etc. All that's needed is that both parties use the same crypto program and agree on an authenticator. I confess to being a hobbiest. If anyone wants the WINDOWS C# .NET program and or the source code they may have it/them. –  user1477194 Sep 7 '13 at 16:43
Your question has been put "on hold" (by me) as it is not clear what you are asking. The first part describes a protocol (which "works", i.e. the message is readable by Alice, when you have a commutative cipher, but for being secure in this usage the cipher needs more properties than a "normal" cipher), and the second part seems to be kind of an example with your cipher implementation which nobody knows. In your comment you mention an "authenticator", but it is not clear how it relates to the rest of the protocol. –  Paŭlo Ebermann Sep 7 '13 at 17:41
If you throw away the second part and find a real question to ask (like "what properties of the cipher are needed so this protocol works and is secure", or "can such a protocol be secure"), the question might be reopened, but as it is, there is no real way to answer it. (Please note that you can edit your question, there is an "edit" link below it.) –  Paŭlo Ebermann Sep 7 '13 at 17:43
thought my question was pretty clear,i.e.,"Why not use this secure symmetric key exchange?" An answer would be because such and such. I don't have any problems I need answers for. I think it's a good protocol and wonder why we needed DIFFIE-HELLMAN and PGP. Any good commutative, complex cipher with rounds, not simple XORing, would work. Authenticate with certificates, signing, salting of the plain text, etc. –  user1477194 Sep 8 '13 at 0:18

Because that requires secure commutative encryption
and takes 3 rounds (despite being unauthenticated).

What makes you think that "a 'man in the middle' attack will not
work if the algorithm is not a simple 'xor'ing of plain text and key"?

The part of your post after that statement only describes
an eavesdropping, despite referring to "man in middle".

-

Here is how a Man-in-the-middle attack would work against your protocol.

We assume Bob wants to send a message to Alice, but Mallory plays man-in-the-middle.

Then your exchange could look like this:

1. Bob encrypts a message $m$ with his key $K_B$: $m_1 = E_{K_B}(m)$.
2. Bob send the result $m_1$ to Alice, but Mallory intercepts it.
3. Mallory encrypts Bob's encrypted above message with his own key: $m_2 = E_{K_M}(m_1)$.
4. Mallory sends his encrypted message $m_2$ back to Bob.
5. Bob decrypts this message with his key: $m_3 = D_{K_B}(m_2)$.
6. Bob sends $m_3$ to Alice (i.e. to Mallory).
7. Mallory decrypts this with his key: $m_4 = D_{K_M}(m_3)$.

Now Mallory has the message which was intended for Alice. He can now read the message, maybe change it, and then forward the same message (using the same protocol) to Alice (or decide to not send it, or send it to someone else).

So some kind of authentication is needed.

Authenticate with certificates, signing, salting of the plain text, etc.

You should include the details of this into your protocol.

As mentioned by Ricky Dehmer and nightcracker, you also need a commutative cipher which doesn't allow the kind of arithmetic that Nightcracker shows ... I know of no such one.

You claim to have such one in your program, but I don't really believe this. (But the question if such ciphers exist is a different one. I think one could build something like this based on RSA, but this wouldn't be a symmetric cipher anymore.)

-