Using my own security algorithm on a tcp connection

Question

I know there are several techniques out there to encrypt data. I am not familiar with them so I been thinking on a way to make my application more secure. I basically have a server application and a client application. The client application sends data to the server app. anyways if you are probably familiar with this protocol you'll know that every thing that get's written to the network stream will be received by the other party. I am basically sending bytes. so my algorithm is something like:

I have a byte array ready to be sent to the server. Modify that byte array. all the bytes that hapend to have values greater than 0 and less than 50 add 5 to them. all the bytes that are greater than 49 and less than 100 add 2 two them. and keep doing the same thing for the rest of the bytes.

and then on the server side I will have the reverse technique.

will this be secure? how will someone sniffing packages will be able to find what I am sending?

---

Edit

Thanks guys for the help. I been thinking about algorithms and I came up with several ones:

technique 1

Let's say I want to send the byte[] {5,89,167,233,23,48,79}

first step: I will add a random byte to index 0 of the array:

so now the new byte array is {X, 5, 89, 167, 233, 23,48,79}

let's assume that x came out to be 75

if is greater than -1 and less than 50 I will apply algorithm number 2 two it. If it is greater than 49 and less than 100 I will apply algorithm 3 two it... etc...

In this case we will use algorithm 3:

so algorithm 3 will basically change the order of every 3 consecutive bytes so the actual byte that I will send is: {X, 167 (last item of the three consecutive bytes), 5 (first item), 89 (second Item), 48 (last item of the next three consecutive bytes), 233 (fist), 48, null,79,null)

get read of the null bytes in order to get {X, 167, 5,89,48,233,48,79}

------->

now the server will get {X, 167, 5,89,48,233,48,79} recall that x was 75 therefore it will apply algorithm 3 to decrypt. it will be basically the same thing in reverse order.

so it will do { 5 (the second item of the first three consecutive bytes), 89 (the last item), 167 (first item of those first three bytes),

233 (the second item of the next three bytes), 23, 48,

79

then the server will have 5,89,167,233,23,48,79

if X will have been 1 for instance I will do the same thing but instead of doing that in chuks of three I would do it on chunks of 2. basically flipping bytes. if x would had been 130 then do the same thing in chunks of 4....

---

I am not going to place the next technique. I may come up with several techniques I love algorithms lol.

I have to say that I agree with all of you let me show you why...

I think I have to be thinking what a hacker will do. I will probably be a bad hacker since I don't know about encryption but I thought about this. Ok I am a hacker and I want to be able to see what is being sent through the network. so if I am the hacker and I see {X, 167, 5,89,48,233,48,79} I will not be able to say nothing right. But since I am a clever hacker I get the program that streams those bytes in order to try to figure it out. I will then use the program to send something easy such as a file that contains the bytes {0,1,2,3,4,5,6}

by sending this bytes several times the hacker is going to be able to see stuff like:

{ 45, 1,0,3,2,5,4,6}

then maybe

{44 1,0,3,2,5,4,6}

.... etc

from that point of view now I understand why it might be easier to figure it out.

Answer 1

A good encryption CAN'T depend on the algorithm, it must depends on the key! The encryption algorithms are well known standards and rely on the secretness of the key, not of the algo!

Answer 2

First off, your scheme can't decrypt since eg 47 becomes 52 and 50 becomes 52, also. Second, it's insecure since anybody with your algorithm can easily decode your ciphertext (well, at least as well as you can, given that not even you can decode all messages). Moreover, a simple frequency-based approach would work since this is essentially a substitution cipher...

Answer 3

I am not familiar with them so I been thinking on a way to make my application more secure.

Stop right there. Being unfamiliar with solutions that already exist isn't a reason to try to invent, from scratch, a new solution that is at least as secure as those solutions that do already exist. Your efforts should be directed towards becoming familiar with at least one of those solutions, ie SSL. I assure you it is infinitely more secure than anything you are likely to come up with in the short term.

And of course as you have just published your algorithm, it is already insecure.