Things not to do with client-side script
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.
Comments
- Anonymous
November 29, 2003
Also plug into the CryptoAPI all you want. But what is the use of strong encryption in the face of poor crypto protocol design? They go hand in hand. - Anonymous
November 30, 2003
GeoTrust sells SSL serever certificates fro aprox. $100 9x cheaper than VeriSign and I am sure it took more than $100 worh of time to write this script, although I do think its cute. - Anonymous
December 01, 2003
You can get a certificate for even less than that...http://www.instantssl.com/ssl-certificate-products/ssl.html.$49/yr for a domain. - Anonymous
December 03, 2003
The comment has been removed - Anonymous
December 03, 2003
The comment has been removed - Anonymous
December 03, 2003
Norzilla, thanks for your remarks. The problem is not so much that I believe there are bugs in the implementation or that the people who wrote the code are incompetent (although obviously I would recommend using a platform-provided service rather than writing your own any day). The problem is that something like this will be ABUSED by people who do not know any better. If you read the Slashdot posts, you would see people thinking of this as a cheap way to get secure HTTP traffice without paying for an SSL certificate. That's just plain wrong -- there's no secure way to use symmetric encryption at the browser level without having previously communicated a secret key (which would require, uh, something like SSL). Something like this is a nice tool to play with, but it's not really what the web needs. I guess my post was more a reaction to the Slashdot comments rather than to the technology itself, but I fear this will be what the majority of people will think of when they see the site. "Why have encryption in the browser if not to secure web site communication?", the thinking will go.Also, you don't need ECMAScript to be cross-platform; any number of languages would have worked equally as well. Like, say, C, Perl, or even Java. ECMAScript is not designed for this kind of task. It's designed for displaying menus on web sites or doing simple form evaluation. To be able to verify the correctness of this code, you not only have to be an expert in AES implementations (which very few people are), you also have to be an expert in ECMAScript (which very few people are). An average Java or C++ developer cannot expect to read ECMAScript code of any degree of complexity and understand what is going on. - Anonymous
December 03, 2003
The comment has been removed - Anonymous
December 04, 2003
The comment has been removed - Anonymous
December 04, 2003
Agreed. I don't (in general) believe in keeping information secret from The Great Unwashed. But in this case it isn't about handing them information (let alone "knowledge"); it's about handing them a tool which they don't understand. Very different ;-)(Glad to finally have some comments on my blog.. I should make more outrageous and controversial posts in the future <g>) - Anonymous
January 29, 2004
I agree with many of your points... however, I recently began using that script for the purposes of communicating certain sensitive content via email to co-workers. Not password sensitive, but "I don't want my bosses reading this" sensitive. It's ideal for that purpose because we've got a few platforms to deal with and we are able to communicate keys beforehand. Is that a poor use? I realize that there are other methods, but without drawing too much attention to ourselves (installing extra software, keeping any keys on our drives) we accomplish our goal.