1

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.

Tono Nam
  • 34,064
  • 78
  • 298
  • 470
  • 4
    why not just use HTTPS? - some smart people figured out transport security already. Also your approach won't work since server cant tell the difference between 48 and 51 when it receives a 53 – BrokenGlass Sep 03 '11 at 15:07
  • 3
    That's easy to break... IMHO... You need to use a proper encryption function, like RSA for example – Tony The Lion Sep 03 '11 at 15:07
  • If you work with .net and you don't want to use TLS (https), then it is really worth to invest some hours into encryption technologies. MS makes it very easy to use commonly accepted and tested security algorithmns with the .net framework! – HCL Sep 03 '11 at 15:10
  • @brokenglass I have never use it. Just wanted to know if that algorithm will be secure. I mean how will you be able to figure it out. I can even change the algorith everytime a file is sent. So the fist time I send a file I will use that algorith. The next time a differnt one and lastly yet another one. And start again. I mean you can think of realy complicated algorithms and Its hard for me to understand how can someone figure it out. I know I am still ignorant on this subject thats why I asked this question fist before implementing my algorith :) – Tono Nam Sep 03 '11 at 15:12
  • See my answer below. As soon as your security depends on the secrecy of the algorithm itself, you've lost. Using multiple algorithms doesn't change this. – Patrick87 Sep 03 '11 at 15:15
  • “I am not familiar with area X, so I will create my own solution” is very often a certain way to failure. – svick Sep 03 '11 at 15:36
  • 2
    If you are not familiar with existing algorithms, then your chance to invent your own and beat existing in security is less than a chance to win in a lottery. – Eugene Mayevski 'Callback Sep 03 '11 at 15:40
  • Secure cryptography is insanely easy... to get wrong. If the data being exchanged has *any* value, then you're doing your users a disservice by not learning enough to know not to try to build a cryptographic solution yourself. – Damien_The_Unbeliever Sep 03 '11 at 15:43
  • Here's a [recent paper on a break on AES](http://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf). AES is (still) trusted, generally, despite this break. If you can understand this paper fully, you're a better developer than me. – Damien_The_Unbeliever Sep 03 '11 at 17:08

3 Answers3

5

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!

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
Simone
  • 2,261
  • 2
  • 19
  • 27
4

First off, your scheme can't decrypt since e.g. 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...

Patrick87
  • 27,682
  • 3
  • 38
  • 73
  • frequency based approach might work on text files, probably not on arbitrary binary files – BrokenGlass Sep 03 '11 at 15:22
  • No binary file it's really arbitrary! – Simone Sep 03 '11 at 15:35
  • @BrokenGlass text files are sent as binary sequences anyway – oleksii Sep 03 '11 at 15:40
  • yeah true that algorithm does not work. but if you spend some time thinking about it I am sure you can come up with several algorithms. – Tono Nam Sep 03 '11 at 15:47
  • @Tono Nam - a great many people have spent *years* thinking of suitable algorithms, and they still sometimes get fine details wrong. What make you believe that you, with *no* experience of writing or analyzing cryptographic algorithms, will get it right on your 1st (or 2nd, or 5th, or 20th) try? – Damien_The_Unbeliever Sep 03 '11 at 16:01
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, i.e. 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.

user207421
  • 305,947
  • 44
  • 307
  • 483