This program encrypts or decrypts typed text and displays the result. The algorithm, which is of course visible in the JavaScript source for this page, uses a key with a default value that is intended to generate XML safe text from XML safe text. In other words, if the original input can be safely placed into an XML file, then the encrypted text will also be safe. If you change the key, the result may include unprintable characters that are not XML safe.
Note that the encryption result using the default key will not be 7-bit ASCII. If you use this to encrypt an email message, depending on your email client and settings, the client may not maintain the same value for some characters. In other words, when you paste the encrypted text into a send window and send it, and then the recipient opens a window for the received email, it is possible that some encrypted characters will be different than originally sent. (I noticed this particularly with Outlook.) This is not a bug in my encryption program; it's a behavior of your email program. You can get around this by saving the encrypted text into a document and attaching the document to the email. I have seen funny behavior with carriage-returns and commas. You won't see the funny behavior unless you pass the text through your email client. It all works fine when pasting encrypted output back into the input field.
This simple algorithm is not intended for applications that need high security. It obfuscates text in a way that the result will not match any natural language and will not be recognizable to someone reading over your shoulder. Of course, it will be so unrecognizable that the reader will wonder what nefarious plans are up your sleeve. If someone wanted to break the code, even without the original JavaScript they could eventually guess at how the characters are transformed.
To decrypt, simple paste the encrypted text into the input window. The decrypted result will appear. In other words, the algorithm as it appears in the source JavaScript is self-reversing.
The input does not need to be 7-bit or 8-bit ASCII, but if your true intent is to be XML safe, you should test with expected input before you deploy critical applications. For example, I tested Arabic letters and was able to decrypt the result into the original entry, but I did not try to put Arabic or encrypted Arabic into an XML file.
JavaScript code Copyright 2010 by Gary Gocek - brought to you by gocek.org!