Even in "Intranet" environments, where the risk of hacking or "stealing" of connection strings is usually very low, nervous managers always seem to want to see connection strings either encrypted (when in a configuration file) or stored in the Registry, or "something" similar such that the plain text connection string is not easily visible to the "casual hacker".
While there is a tool for encrypting various sections of a standard .NET configuration file, it can prove to be more of an annoyance than a benefit in some situations. I've found that cautious managers can often be satisfied with simple XOR encryption, which makes things orders of magnitude easier for the developer.
Now let me just head you flamers off at the pass, so we can get on to the real issue:
1) XOR against a string of text is NOT a strong encryption algorithm. It would probably be one of the FIRST things a determined hacker would try.
2) If you do choose to use XOR, be advised that you could end up with "non XML-safe" characters.
3) If you need strong encryption, DO NOT USE XOR algorithms. OK? Rest my case.
There. Now let's get to the details. What is XOR? XOR normally stands for "Exclusive OR" and is a logical operation on two operands that results in a logical value of true if and only if exactly one of the operands has a value of true. When applied to the ASCII values of a string of text (char), it has the effect of resulting in addition with no "carry". So, if you XOR an "a" (ASCII 97) against 129, you get ASCII 224, which is an "a" character with the Accent aigue (left-pointing accent), and so on. If you choose the value that you will perform the XOR operation to each character with carefully, you can be sure to always get characters that can be placed in an XML element (your config file) without any illegal XML characters. Such a value is 129, which is what I use in this example.
In other words, every lower-case letter, upper-case letter and numeral and common symbol in the ASCII character set XOR's against 129 to result in another character that is "XML - safe" - including all the characters: !@#$%^&*()?<>/\:;"'
You can experiment with other values using the provided downloadable Visual Studio 2005 Solution and Windows Forms test harness.
In C#, we XOR one value against another like this: A ^ B
There are many variations of XOR algorithms, such as ones that use a different XOR operand for each subsequent character in the string to be "XOR-ed", but the key advantage of this algorithm is that it is symmetric. If you get a translated value by XOR-ing it against 129, and then XOR the translated value against 129, you always get back the original character's value. ALWAYS.
What that means is that you only need one method, "EncryptDecrypt". Pass a string into it and get it back encrypted. Pass the encrypted string into it and you get back the original text, as long as the XOR character is the same. The code is childishly simple:
public static class EncryptorDecryptor
public static int key = 129;
public static string EncryptDecrypt(string textToEncrypt)
StringBuilder inSb = new StringBuilder(textToEncrypt);
StringBuilder outSb = new StringBuilder(textToEncrypt.Length);
for (int i = 0; i < textToEncrypt.Length; i++)
c = inSb[i];
c = (char)(c ^ key);
This will turn this string:
-- and back again, which in many cases, is "just enough" to keep things from prying eyes.
You can download the complete solution here