-8

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.

Scruffy
  • 123
  • 5
  • What you're describing is "security by obscurity". While it might fool the "internet cafe owner", it most certainly won't withstand the scrutiny of _any_ security research. – efr4k Dec 18 '14 at 10:50
  • Why on earth would you call that security? It's not even "... by obscurity". It's like that guy from the kids' song, Yankee Doodle - just cuz you call it "macaroni", doesn't mean it is anything BUT a feather. – AviD Dec 18 '14 at 11:31
  • 2
    Q: "If you call a dog's tail a leg, how many legs would the dog have?" A: "Four, because it doesn't matter a damn what you call the tail, it's still not a leg." – AviD Dec 18 '14 at 11:32
  • I was referring to the expression "security by obscurity", which I don't find to have anything to do with real security. I think we agree, but maybe not on the meaning of the expression :P – efr4k Dec 18 '14 at 12:31

5 Answers5

11

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.

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
2

You are in the situation, that your client and server alreay share a secret (your algorithm adding 42 to each byte). While this is a very unsecure implementation, it would be possible to encrypt the content with a strong key and your message would be safe.

The problem is, that as soon as somebody gets the secret (however he does it), he can read your message. An encoded text is no problem for any attacker, encryption is.

SSL on the other side is capable of encrypting your message, even if your client does not have installed anything (no shared secret is available). It does it with the certificates, which can be verified with the installed root certificates of your browser.

martinstoeckli
  • 5,189
  • 2
  • 27
  • 32
2

I'm not sure who this is intended to stop -- the encoding scheme described is barely strong enough to defeat a "clueless eavesdropper"-class threat, and is incapable of stopping or even significantly slowing a "nosy little brother"-class attacker. Someone with the technical capabilities to perform a successful SSL "man-in-the-middle" attack as described in the question should be able to see right through it.

Mark
  • 34,513
  • 9
  • 86
  • 135
  • Heck, I would even say "anyone with the technical capabilities to intercept your message over the air" would be able to see right through it. – AviD Dec 18 '14 at 11:34
2

What you have implemented is something very similar to the "Caesar cipher" which has already has been used in the 8th century. It is easily breakable with pen and paper. See this article for more information: http://en.wikipedia.org/wiki/Caesar_cipher#Breaking_the_cipher

So basically, no your algorithm does not compare to current TLS implementations. Also see this thread why you should not roll your own cryptography: Why shouldn't we roll our own?

Community
  • 1
Julian Hansmann
  • 31
  • 2
-3

You see a lot of tools for breaking specific protocols, but are there generic tools for hand crafted encodings? In which case, this might be an adequate method for the general public.

mincewind
  • 41
  • 4
  • 2
    It is extremely easy for anyone with the slightest bit of programming background to write a tool to reverse this. You shouldn't assume your attacker is going to play nice and not want to write their own trivial program to decrypt this, because people who assume that frequently get a nasty surprise. This method is inadequate for any mildly competent attacker, whereas TLS is secure against extremely competent attackers if the user pays attention to certificates. This might be suitable for a "spy kit" for little kids, but is utterly unsuited for any semblance of security. – cpast Dec 18 '14 at 14:34
  • Yes, so where are the tools and how would you generalise it? This will help in determining if the standard passer by will take the effort to find something about the use of encryption, if standard ones have a known finite time cost. – mincewind Dec 18 '14 at 14:42
  • I was breaking harder encodings in elementary school -- *without* the use of computers. – Mark Dec 18 '14 at 21:02
  • Granted that may be true. But what is the probability of someone using an automated tool, searching for encrypted streams, trying to break them, being interested in the one outgoing encryption that the automated tool doesn't know about. If you're a standard script kiddie, you'd move on. – mincewind Dec 19 '14 at 04:14