In building a security system, I\'m looking to prevent \'man-in-the-middle\' att
ID: 655822 • Letter: I
Question
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?
Explanation / Answer
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).
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.