[size="5"]Introduction

One of the major problems faced with file and media storage is that they can be easily viewed and edited by end users, or unauthorized users. When it comes to releasing online games, applications, and so forth, you may want to try to avoid this as to prevent hackers from easily gaining access to critical information.

Well in an attempt to address this problem in a program I was recently working on (which required sensitive and unique transmissions) I looked around the Internet and had a hard time finding great details of information on encryption algorithms. With this in light, after some help from a colleague, I decided to write a simple article on one layer, one key XOR based encryption.

Unlike other forms of encryption, such has ROT13, or what I personally like to call bit shifting encryption where characters are changed to a different value without the use of an independent key or algorithm, XOR based encryption is essentially one of the most secure. To demonstrate, though I am sure many of you are already aware of the properties of an XOR operation, I will explain first how the XOR works.


[size="5"]The XOR Gate and why it works

The XOR gate (also known as the Exclusive-OR gate) simply looks for two bits and will return one. It performs very much like an OR gate only it does not allow for both bits to be active. (Only the first or second gate can be active for it to return true, otherwise it will return false).

Presented is a copy of the truth table:

Input Bit 1Input Bit 2XORed Output000011101110Now, let's take the binary string 1110001100101 - This string can be the binary equivalent to any character(s); what is relevant though is that you understand the importance at a binary level.

Well now that we have something to encrypt, let's generate a key. 101 will be the key in this example. This key can be the binary equivalent from a character or string, same deal as above.

Now with this, all we have to do is XOR the string to encrypt with the key and we get the encrypted string. Since the key is not as long as the string we wish to encrypt we will be required to cycle the key.
Now we have an encrypted string safe for storage or transfer (encrypted with a 3bit encryption key).

Next, to decrypt the data all we have to do is reXOR the encrypted string with the same encryption key:
The original string has been recovered and is now good for use again.

However, should a false key be used for the decryption, the data remains encrypted.

[size="5"]Problems with Online Implementation

The largest problem with this form of encryption is that you must always know the original encryption key used in order to properly decrypt the encrypted data. For simple file storage and retrieval this is not a problem as typically only one user will have access, or the key is transferred in another secure method to the other users.

TCP and UDP connections do not work like this unfortunately. Transmitting the key as clear text over the internet is just as bad as not having the data encrypted and if that is the intent, then you may as well not bother encrypting to begin with.

Writing the keys directly into the program also poses a problem, that if there exists more then one copy of the server / client, then they can easily be used to decrypt the other's data since they both contain the same key. While on the other hand, writing individual keys into each client, and then all of those keys into the server requires that the user identify itself in clear text, and also causes the problem that each key has to be encoded. For a subscription service, one could even use an account number as their key, though it may not take a whole lot for a hacker to realize this and, knowing a user's account number, exploit it.

One of the systems developed to overcome this situation is the dual key encryption, which is a commonly used system for PGP based encryption as some of you may already know.

It works by generating two keys, more commonly the public key and the private key. The public key would be sent to a person to encrypt the data, and after that it's no longer used, and the private key remains the only one capable of decrypting the data.

Both server and client generate the two keys and exchange public keys (since they cannot be used to decrypt). They then commonly send a challenge - a random string for the other end to return encrypted where the originating end then decrypts and verifies.

Dual key encryption requires a fair deal of explanation and will be explained in a later article, likely over the Christmas break when I have some more time off from school and work.


[size="5"]The Code

Contrary to popular belief, the code for this is actually very simple. Though there are many small ways to help protect your keys and your data through data shifting, or even XORing the encryption key against another preset value or a second key, ultimately 1 XOR is enough in many cases where extremely sensitive information is not being broadcast.

Essentially what this does is simple (starting at the address of both strings): loop through and XOR each character respectively. If the encryption key is shorter then the key to encrypt, the addresses will wrap around back to the beginning of the string. If it is longer, the end will just never be reached and the loop will terminate with the properly encrypted string.


[size="5"]Conclusion

Though not best suited for Internet use, single key encryption works great for file storing and retrieving providing the ability to protect data, and applications from tampering or unauthorized viewing.