I am writing a client / server program pair. I have established my own protocol

Question

I am writing a client / server program pair. I have established my own protocol and am communicating with TCP. Presently, when the client messages the server, it adds 42 to each byte (looping, 127 + 1 = -128) and reverse the byte array to send. The server side subtracts 42 from each byte and reverses the byte array again. This delivers, to me, easy-to-implement security.

Compared with SSH/HTTPS level SSL with handshakes, 128-bit private and public keys, et cetera, which is more secure? That is, if I do HTTPS at some dodgy internet cafe, the owner can pull some tricks to make 'secure' connections between their loan computers and GMail, for instance, to make my traffic Wireshark-style sniffable, whereas, if an internet cafe owner looks at a packet capture of (+42, reverse) encoding, they would likely be at a loss for decrypting it.

Explanation / Answer

What you have defined is not security.

SSL can give you security.

So...your question is easy to answer:

Yes - SSL is up to 100% more secure than encoding. While elements of your 2nd paragraph have some basis in fact (there are malicious MITM attacks etc) they can be protected against, whereas your solution has no protection, and is easily decoded by anyone.

Your assumption 'they would be at a loss' is completely false, I'm afraid. Anything that looks like encoding is incredibly easy to find and break.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.