Data encryption can be a very complex area. Most modern, secure encryption algorithms are very mathematic in nature and would require a lot of studying to understand. There are, however, some algorithms that are very easy to implement, and when used properly can be very secure. XOR-encryption is one of them. With this method you simply perform a bitwise XOR on each byte of the data you wish to encrypt with some key. When you want the original data back you just do the same thing: XOR each byte of the encrypted data with the same key.
XOR truth table:
Code:
a | b | a XOR b
----+----+---------
0 | 0 | 1
0 | 1 | 0
1 | 0 | 0
1 | 1 | 1
The following is always true:
If ((a XOR b) = c) then ((c XOR b) = a)
In the most simple form of this encryption you use just one byte as the key. For example, the Linux C library function memfrob() uses the number 42 as the key. This is of course very insecure, since anyone could just memfrob() the data back without having to figure out the key. Even if you do not know the key, figuring it out is not that hard. Since the key is just one byte, there are only 256 possibilities for the key. Any computer built in the last few decades can test every key in a few seconds.
A more secure version of memfrob() would take an entire string as a key. As it XORs the data, it goes through the string, byte by byte, using the bytes in the string as individual keys in the XOR operations. Anyone who would use this improved memfrob() to retrieve the original data would have to know the entire key. But exactly how secure is this? Well... It all depends on how long and complex your key is, of course. See, if someone knows a part of the unencrypted data, and the length of the key, they can use that part as a fake key temporarily. When using this fake key to decrypt the data the real key will turn up somewhere. If, for example, you encrypted a personal document, then it probably has your name at the top. Someone could use your name as the key and that would find the real key hidden somewhere in the document.
This happens because the following is always true:
Code:
If ((a XOR b) = c) then ((c XOR a) = b)
So for example, if an HTML file is encrypted, and you don't know the key, you can use the fact that it is an HTML file to find the key. Say you know the key is 6 bytes long (and even if not, you can simply try various lengths). You could try to decrypt it with "<HTML>" as the key and then look for anything suspicious in the decrypted data (most of the data will probably look like garbage) that looks like a password. If the decrypted data after using the temporary key looks like this:
...ä? #¤Bïhellohå... and so on
Then you could probably guess that the real key is "hello" and easily decrypt it. This implies that the only way to have a really secure key, is to have one that is so long that you're certain that no one knows a part of the data longer than the key. Thus, if you know that no one knows more than 10 bytes of the original, a key that's 11 bytes long will be secure.
Unfortunately, this is not always the case. If your key is the word "secret" and someone knows 5 bytes, and finds the string "secre" when they unencrypt with those 5 bytes, they might be able to guess that "secret" is the real key. Therefore, don't use regular English words as the key and instead use keys that appear random like "Kiox09Zx!", and use long keys (the definition of "long" is relative to the size of the data).
If your key is just 1 byte long, it will be very easy to crack. If the length of the key is the same as the length of the entire data, it will be totally unhackable. In fact, the United States Army uses codes of this type in top secret military communications. For normal purposes though, a key like "Kiox09Zx!" is probably good enough. If you want really good security, you could use a file's content as a key, or an entire CD-ROM disk with random data.
Reply With Quote
