Things not to do with client-side script

  • Article

Browsing Slashdot, I saw an article about some browser-based encryption code called JavaScrypt (ha ha, funny name guys). I thought this was funny since I used to be the PM for JScript and now I spend some time thinking about security. Quite what the purpose of this tool is, I don't know. It seems to let you encrypt some data inside your web browser, and then... uh... look over there! It's Keanu Reeves!

As some of the comments on the article point out, the algorithm used is AES, a symmetric algorithm that requires a single secret key for both encryption and decryption (as opposed to asymmetric algorithms that use different keys for encryption (public key) and decryption (private key)). So although you can encrypt information using only your web browser, you can't actually send that information to anyone without also sending them the secret decryption key... and how are you going to do that? Probably in the same message / packet / HTTP request that you send the encrypted data in. Oh dear. Hope nobody is suckered into thinking this is "secure."

To be fair, the web site does suggest using keys that are communicated out-of-band, but the average user is not going to do this, especially a naive internet user who is conversing with someone on the other side of the world whom they've never actually met in person.

Another "cool" thing about this is that the site promises no data is ever sent from your machine back across the network, so it must be secure. And how can you be sure that no data is ever sent across the network? Because they let you download a ZIP file purporting to contain the source code, and then tell you in bold text that "Nothing is sent to any Web site when you encrypt or decrypt a message!"

Wow.

Say it with me now:

"W...O...W"

So now if I'm an ultra l33t h4x0r then maybe I can download the ZIP file, read the contents, completely understand it, and then install it on my local machine and use it as a local application. I certainly can't download the ZIP file, completely understand it, and then use the site on the web. Why? Because there's no reason why the stuff on the site has to be anything like the stuff in the ZIP file. (Not that I'm saying I think the people hosting the site would do that; just that it's a really bad thing for people to think that what they downloaded yesterday in a ZIP file is the same as what is on the live web site today).

The last thing we want to do is get into a world where people believe that just because a web site says "You can trust me because of XYZ" that they really can trust the web site because of XYZ without providing some other independent evidence. (And no, source code is NOT suitable evidence for the average person!). People are already confused enough about the web to submit all sorts of personal information into web forms embedded in e-mail messages claiming to be from AOL or ICQ or their bank. This kind of thing can only make things worse if it catches on.

But if this is only useful as a local application, why make it into a browser app at all? As Eric Lippert will tell you over and over again, ECMAScript really isn't the right tool for this kind of job. And as Michael Howard (and anyone else with a security background) will tell you, you should never write your own crypto code. (And you know that must be true because I just said it in bold text on a web page!). Use whatever libraries your platform provides. For Windows, that would be CryptoAPI and for .NET it would be System.Security.Cryptography. Obviously those don't provide the same kind of cross-platform support that ECMAScript does, but you still have Java Cryptography Extensions which should work most places.

One other funny thing: In one of the Slashdot comments, somebody said that they implemented some kind of browser-based encryption because their employer was too frugal (that's a euphemism for "tight" :-) ) to purchase an SLL cert. You can get a 1-year 128-bit cert from VeriSign for under $900, which is probably less than what it actually cost to develop and test the home-grown encryption (and almost certainly is more secure and carries less risk associated with it).

Now I'm sure this was a cool project to work on, and the people that did it were likely very smart and talented individuals. I don't want to sound completely negative. It's just that this sort of thing (pointless technology) isn't really what we need to help make the web a better place. We need better education.