As mentioned in the original story, I started with the output decryption script and had to go back and recreate the encryption portion of the page from scratch. My priorities in implementing the encryption side were as follows:

• Full Javascript implementation (I have no idea how popular this may get, and don’t want this to burn either significant bandwidth or CPU cycles – so everything runs on the client).
• Full compatibility with existing scripts (I want to make sure that people using the existing script can use this encryptor to add new Email addresses without having to make any changes, and while continuing to use the script they downloaded previously).

Naturally, this meant digging in to what the previous author had done. You’ll find that the code you download to decrypt email addresses remains completely unchanged – to see my work you’ll have to look at the page source on the encryption page.
Along the way I naturally began to wonder – is this anti-spam approach any good? The answer as it turns out is: yes, but the encryption doesn’t buy you what you might think it does.
Let’s start with one basic fact: any web page designed to display an Email address must have all the code necessary on the page to display the address. That means that it is theoretically possible for a sophisticated enough spam harvester to get the address. This is true for ANY approach. So what we’re really talking about here isn’t encryption (though we are using encryption), it’s obfuscation – hiding the Email address.
What is interesting about this approach is that it actually is using encryption (RSA encryption specifically). Which means, curiously enough, that two interesting things happen:

• First, the use of RSA encryption makes it very hard for someone to create new Email addresses unless they have the original key values that you used. This is irrelevant in terms of protecting you from spam – it just means that without an encryption page such as the one I’ve created, it becomes very hard to add new Email addresses.
• Second, because this is encryption, you actually can use this page to truly encrypt other kinds of data and give it some protection by leaving the keys out. You can do this by removing the first two numbers from the array (this is the key data), and passing that data (perhaps received from user input) to the decryption function. For example, if you have an array line:
  addresses.push(“3131 2143 1806 2806 830 “);
  You could remove the 3131 and 2143 and call decrypt_and_email(1, 3131, 2143).
  Of course the number of bits being used here is very small, so the protection you have is very limited and easily susceptible to a brute-force attack.

The other thing you’ll see when you look at the code are some.. well, let’s say perplexing choices. For example: a cryptographer will note that the exponent and y parameters of the exponentialModulo function are seemingly reversed. Actually, it works fine – it’s just the naming that is backwards, with the exponent being used as the modulus and the y value as the exponent. It’s also not clear why the author bothered with a caching scheme – as it only provides benefit when you are using the same Email multiple times on a page – not a likely occurrence.
Overall this isn’t a bad solution to protecting Email addresses from being harvested. You definitely should clear the comments – those are easily harvested and putting an – At – in the middle is a pattern that is easily detected. Leave the encrypted data in the included javascript file instead of on the web page – harvesters are less likely to process included javascript files.