views:

197

answers:

2

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#.

+1  A: 

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.

Cheeso
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
A: 

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

acidzombie24