Simple XOR encryption

[ultifinitus]

Alright, beginner's encryption lesson:

everything on a computer is stored as binary data, in the form of bytes (8 bits, or individual 1's or 0's)

Binary data can easily be "encrypted" with a "key" based on a little boolean operation called an xor, or exclusive or.
when we xor a single bit (a 1 or 0) with another bit:

if 1 bit is true, and 1 bit is false, it returns true, otherwise it returns false;
sooo:

1 xor 1 = 0
1 xor 0 = 1
0 xor 1 = 1
0 xor 0 = 0

now one reason this is useful is if we take the new bit and xor it with the same key (the second bit) the result will always be the first bit.
so:

1 xor 1 xor 1 = 1;
1 xor 0 xor 0 = 1;


Of course on a single bit, it wouldn't do much good, but when you get into higher levels of memory it's a fairly simple and (sometimes) effective (see later in article) encryption method.

Now when I say everything is stored as binary data, that also means strings, a single char is stored as either ascii or unicode (or some other protocol, but those are the only two I've seen) values.

for example:

The letter 'h' in ascii = 104
The letter 'i' in ascii = 105

converting from an integer to a binary number is a little difficult, but doable.
when you look at a binary number, you can read it in reverse and add the value of each bit, which is as follows

2^x 2⁵ 2⁴ 2³ 2² 2¹ 2⁰

so the binary number
01110011

0    1    1    1   0   0   1   1 
0 + 64 + 32 + 16 + 0 + 0 + 2 + 1

is 115 or 's'

now that's all well and good, you can send little notes to your friends, and no one can tell what the heck your saying, but of course you could just write the binary stuff, and it would perform the same action =)

In c++ the ^ operator is the xor operator.
if I have a string, that I want to encrypt, I can do something like this:

 string toEncrypt = "fail";
 char keyToEncrypt = 's'; //remember 115 in ascii

 for (int temp = 0; temp < toEncrypt.size(); temp++)
   toEncrypt[temp] ^= keyToEncrypt;
 cout << "nThe encrypted data = " << toEncrypt;

 for (int temp = 0; temp < toEncrypt.size(); temp++)
   toEncrypt[temp] ^= keyToEncrypt; //notice we're using the exact same key, to unencrypt the data.
 cout << "nThe unencrypted data = " << toEncrypt;

Of course this is all well and good, but here's an excersize for anyone who's using a simple key for their data, if someone has access to your program. And they can encrypt some data of their own, and have access to the output of that encryption, they can get your key. Example:

 char original = "f";
 char key = "s";
 char end;
 char getKey;

 end = original ^ key;

 // now here's the kicker

 getKey = original ^ end;

So you have to get tricky, one reeeeeaaaaly easy way to encrypt and decrypt the data a little more securely, could be something like this:

 string original = "super flying monkeys are aweseome, aren't they?";
 cout << "Original data = " << original;
 string encrypted = "";
 string unencrypt = "";
 char key = 'x';

 for (int temp = 0; temp < original.size(); temp++){
  encrypted += original[temp] ^ (int(key) + temp) % 255;
 }
 cout << "nEncrypted data = " << encrypted;

 for (int temp = 0; temp < original.size(); temp++){
  unencrypted += encrypted[temp] ^ (int(key) + temp) % 255;
 }
 cout << "nUnencrypted data = " << unencrypt;

Of course, you can should do something other than simple incrementing, because that's pretty easy to sniff.

But there you have it, a simple encryption lesson!

[oldnewbie]

As an absolute beginner,I think this is good tutorial/article.

[ultifinitus]

Awesome! I had hoped it would be helpful!!

[ultifinitus]

Also thinking about writing an article on simple collision detection and resolution, anyone interested?

[m4ster r0shi]

Cool. Now, try public key cryptography.

You could begin presenting the basic problems public key cryptography is based on
(big integer factorization, discrete logarithm problem, etc...).

Then, present a cryptosystem for each of these problems (RSA, ElGamal, etc...).

Finally, write a word or two about security notions and how you can enhance a cryptosystem's security using hash functions (hash functions => non-malleability <=> protection against adaptive chosen ciphertext attack).

ultifinitus wrote:

Also thinking about writing an article on simple collision detection and resolution, anyone interested?

This is also a good idea.

I happen to have a lot of spare time these days and I plan to spend most of it on SFML.
A good article on collision detection is something I'd like to read.

[hamsterman]

collision detection

that reminds me of an old thread you might find interesting. http://www.cplusplus.com/forum/lounge/30606/#msg167571

[ultifinitus]

@m4ster r0shi:
I think that's a great idea. I'll make sure my understanding isn't flawed, then I'll drop an update on the thread.

And fantastic! I'll definitely write about what I've found!


@hamsterman
I'll talk to (edit)[the relevant people] about adding that to the article too! Thanks.

[hamsterman]

I'm glad you find that useful, but why Kyon? I linked to his post because that's where people start talking about collision. The discussion goes on to the end of the thread.

[ultifinitus]

hahah, sorry, I misunderstood! Back to reading =)

[oldnewbie]

Also thinking about writing an article on simple collision detection and resolution, anyone interested? 

You mean something like basic game physics?Looking forward to it.

[benjelly]

Thanks for this Article!

[tejashs]

what will happen if the encrypted character is a non printable character ie below 32...

[ultifinitus]

With simple xor encryption? It doesn't matter what the original, or the encrypted characters are, it's all binary. Nothing can change the encryption...

(below 32)
00100000 >



00011111 (31) ^

10000000 (128)
______________
10011111 (159)

[Browni3141]

Encryption is easy, how about Decryption with an unknown key? That might make a nice addition.

[ultifinitus]

I agree with you Browni, I'll post some basic cryptography stuff when I get the time. It'll have to be after my long article on collision detection, and it may end up going on my blog...

[tejashs]

can anyone help me with this ... trying to implement this for text files
http://www.cplusplus.com/forum/general/41284/

[Computergeek01]

BINGO! tejashs has nailed the issue with "basic" XOR encryption, that is unless you exclude a lot of characters from the ASCII table there by weakening your encryption a whole ton you can't unencrypt it!

"Was that a NULL? A space that your encryption skipped? Or a collision because that character is the same as the key?"

"How do you parse the words when you go to decrypt it? Did the origional cipher skip the whitespace? Delete the whitespace? Encrypt the whitespace?"

"Is that a TAB? A series of whitespaces? More NULLs?"

"What happens when the cipher cranks out a DEL command? Or anyother control character for that matter?"

I was actually planning on doing some thing like this but these are the questions that have been holding me up on the project. Also my main focus was on cryptanalysis and gathering the data for frequency analysis has been tedious.

[Veltas]

So you're not just able to read the binary of the file? Reading the binary shouldn't give any problems with the bottom 32.

And also I'd simplify any attempt at bitwise encryption by using unsigned chars.

[Computergeek01]

Veltas wrote:

And also I'd simplify any attempt at bitwise encryption by using unsigned chars.

Which, like I said, would greatly weaken your encryption. Again my article was going to focus on breaking the code not making it, so keeping the strength of the cipher intact was a main point of mine. Also, pretending to not know what the user did with special characters, new lines, tabs etc. was another realistic element I was trying to preserve. I guess none of this would be the case for the person that the message was intended for as they would know these things already, so point conceded, good argument.

[Veltas]

Why does using unsigned chars weaken encryption? The only difference is I can enter different integers to store in the same char. Once sent, the binary is exactly the same, it's just easier to use for the person encoding.

EDIT: Anyway, this is all a bit pointless. I could easily make an encryption method that you'd never solve in a million years and no computer on God's earth could solve.

But public key cryptography sounds very possible.