In building a security system, I'm looking to prevent 'man-in-the-middle' attacks in a two-way encryption system, using the following setup:

A sends B a message, encrypted with code 1

B sends it back, having been encrypted with 1 and 2

A reverses 1 and sends it to B, upon which B decodes code 2 and receives the message.

At no point can a man in the middle access this data. Yet this hinges on there being two such functions, that can be nested and decoded out of order. Are there any such functions? Or are there better ways to prevent attacks?

  • 1
    Couldn't A or B be a "man in the middle"? Also, I'm a little confused by the use of "decode" and "reverse" when talking about encryption. Could you clarify this, perhaps using "decrypt" where appropriate? Feb 17, 2015 at 7:08

2 Answers 2


You should not use this in any production system, period. You're trying to design cryptographic primitives, which is something which is extremely easy to get horribly wrong. If you aren't yourself a cryptographer, don't try to design cryptographic algorithms - perfectly good ones already exist. (In general, you should use well-tested systems wherever you can in security - never roll your own primitive, avoid rolling your own protocol wherever you possibly can, avoid rolling your own implementation when practical).

In fact, this scheme is highly vulnerable to MitM attacks. A MitM is not someone who's listening in on traffic; they're active attackers, and can modify any communication going between the two parties. In this case, the MitM intercepts Alice's first message and encrypts it with their key; when Alice removes her encryption, the attacker now has it encrypted with their own key and nothing else. You have to somehow verify that it's Bob's key that was added in step 2, not an attacker's; your scheme doesn't even try to solve this.

A far, far better way to do this is public-key encryption. Alice and Bob give each other their public keys through some out-of-band communication, or a trusted third party verifies their public keys. Alice encrypts her message with Bob's public key, and Bob then decrypts it. You need to share public keys, but that's a plus: in your scheme (where you don't know the key Bob should use nor whether the message was in fact re-encrypted with it), you're extremely vulnerable to a MitM attack.

So use proper public-key encryption in a properly tested protocol, if possible in properly tested library code (note "tested" means "tested for security, which only trained experts can really do).


Your scheme would be totally insecure, even if the underlying encryption is secure.

A one time pad is perfectly secure, as long as the key management is done properly. Your scheme seems to have the advantage, that keys never need to be distributed, which address the main drawback of a one time pad.

So if A and B each generate a one time pad could they use your scheme?

The answer is, yes they could do so. A one time pad does satisfy all your listed requirements. It is provably secure, and if a message is encrypted twice using different keys, the original message can be obtained by decrypting with the two keys in either order.

What would be send in the three messages using your scheme would be m⊕K₁, m⊕K₁⊕K₂, and m⊕K₂. However a passively snooping attacker could simply compute the xor of all three messages to recover the original message.

So even though the recipient could eventually decrypt the message, so could any man-in-the-middle.

I recommend that instead of coming up with your own scheme, you use something more standardized like for example Diffie-Hellman key exchange.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .