0

Background:

I have data that I'm encrypting with javascript on the client side that needs to be decrypted on the server side.

As far as I can tell, the javascript AES library I'm using does not interop with the C# Rijndael library.

Thus, I'm left to essentially implement the javascript AES in C# for use.

I'm going to try to compile the javascript using jsc.exe into a dll and see if reflector can save me some time.

I'm aware that jscript is not the same as javascript, but I'm hoping I can get away with something that works awefully close, and just do the touchups manually.

Problem:

When I compile the javascript using JSC I get the following error:

error JS1234: Only type and package definitions are allowed inside a library

The offending line is this first line in the following lines of code:

var GibberishAES = (function(){
    var Nr = 14,
    /* Default to 256 Bit Encryption */
    Nk = 8,
    Decrypt = false,

    enc_utf8 = function(s)
    {
        try {
            return unescape(encodeURIComponent(s));
        }
        catch(e) {
            throw 'Error on UTF-8 encode';
        }
    },

    dec_utf8 = function(s)
    {
        try {
            return decodeURIComponent(escape(s));
        }
        catch(e) {
            throw ('Bad Key');
        }
    },

And the full source can be found here:

I'm not sure what the problem is. I'm also open to suggestions as to how to encrypt/decrypt data between Javascript and C#.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Alan
  • 45,915
  • 17
  • 113
  • 134
  • I don't have an answer, but I'm just curious why you can't just use HTTPS to deal with encryption between client & server? – Alconja Jul 29 '09 at 00:03
  • It's hard to tell what the problem is, since the line you supplied doesn't do much sense and is not a complete statement. Is it possible for you to add some more lines of code? – kanngard Jul 29 '09 at 00:08
  • @Alconja: Unfortunately I don't have *any* control over using SSL between the client and the server. Some clients will setup SSL, while others will not. Thus all sensitive data must be encrypted on the client side for transmission. @kanngard: Okay I've updated, plus added a link to the full js file. Thanks! – Alan Jul 29 '09 at 00:21
  • **@Alan:** SSL/TLS is supported on all clients. The clients don't need to install anything for it to work. All you need to do is setup your server with a certificate to use `HTTPS`. – Andrew Moore Jul 29 '09 at 00:28
  • @Andrew: Thank, I know how SSL/TLS work. Please trust me when I say I have no control over using SSL. If you have a page that contains both secure (my little javascript) and insecure (the customers page) you will be treated to a nice error message. We have more than a handful of customers who *DO NOT* want this dialog box to pop up, and *DO NOT* wish to use setup SSL on their end. – Alan Jul 29 '09 at 00:43
  • There is a lot of crap techincal reasons why we can't just use SSL and be done with it. Which leaves me with encrypting data. – Alan Jul 29 '09 at 00:52
  • When I compile the linked .js file using `jsc gibberish-aes.js` (reports as compiler version 8.00.50727 for .NET version 2.0.50727), I get two different errors (`gibberish-aes.js(834,13) : error JS1135: Variable 'totalChunks' has not been declared` and `gibberish-aes.js(882,25) : error JS0438: Object doesn't support this property or method`). After fixing those, it compiled ok for me... – Alconja Jul 29 '09 at 02:16
  • Ok, scratch that... I get the error you report if I include the `/target:library` switch. – Alconja Jul 29 '09 at 02:18
  • Although that being said, you can still give the `.exe` produced from `jsc gibberish-aes.js` to reflector which you mentioned is what you were planning on using it for anyway. Although looking at it, its a pretty ugly mess of anonymous methods & closures, so not sure if it'll be of much use to you. – Alconja Jul 29 '09 at 04:37

2 Answers2

1

If you just want to do AES from Javascript, did you try slowAES? It worked for me.. I found good interop between slowAES and the built-in Rijndael or AES classes in .NET. Also I found that the class design was natural and easy to use and understand. This would not require porting from Javascript to JScript.

Password-based-Key-derivation is not really handled by SlowAES. If you need that (likely) then I suggest the PBKDF2 implementation from Parvez Anandam. I also have used that, and it works nicely.

When I tested slowAES coupled with Anandam's PBKDF2, it had good interop with C#'s RijndaelManaged class, in CBC mode.

Don't be put off by the name "slowAES" - it isn't really slow. It's named "slow" because it's Javascript.

If you cannot use something that is clean and compatible like slowAES, then before trying the jsc compiler, I would suggest packaging the existing javascript code into a Windows Script Component. The WSC allows you to package script logic as a COM component, where it becomes usable by any COM-capable environment including any .NET application. Here's a post that shows how to package slowAES as a WSC.

For some reason not many people are aware that you can package script code as a COM component, but it's been around for 10 years. It may sound unusual to you, but it beats doing the port. The code inside the WSC is Javascript, not Javascript.NET.

Community
  • 1
  • 1
Cheeso
  • 189,189
  • 101
  • 473
  • 713
  • Thanks for the suggestions! I ended up biting the bullet and doing the port. Surprisingly it wasn't too bad especially with the aid of the debugger. I kicked around using the WSC method you suggested, but I was afraid of performance. – Alan Jul 30 '09 at 14:46
1

I had this problem today as well. I happen to stumble upon the solution. use package theNameSpace { class Whatever { function func() { return "the results"; } } }