Encrypt at client side and decrypt at server side

[backslashW]

There are persons who think that encryption at client side doesn't work, because if you need to transfer critical information you can always use SSL.

But there is a big exception, and it happens when you have to fight against HTTP header readers.

As not everybody know, headers are in plain text at client side even if you use SSL, and if you use a header reader (like HTTPfox, firefox add-on) you can see any password that the client sends in any form field.

All this introduction was just to see if anyone knows a javascript encrytion library compatible with any othe ASP.net at client side.

By the way, not always two libraries are compatible even if they use the same encryption algorithm, there are a lot of other things involved, like character codes, url transformation, and not always the libraries are strictly implemented.

Any help would be appreciated.
Thanks in advance.

[iam_clint]

one method I have seen to fight this is to md5 the password client side and send the md5 hash to server for verification.

[backslashW]

one method I have seen to fight this is to md5 the password client side and send the md5 hash to server for verification.

Thanks I´m already using your suggestion, but the problem is for other confidential fields that I need to read at server side. That's why I need a simmetric encryption algorithm as AES or Blowfish.

Thanks...

[rnd me]

POST data submitted over HTTPS if encrypted.

<script type="text/javascript"  id = "base">function jcipher(p,s){var i=0,P=0,K=0,b="",Max=0,d=[];if(p.slice(0,3)=="zz,"){var slen=s.length + 1;d=p.split(",");p = "";var junk=d.shift(),Scc=String.fromCharCode; Max=d.length;var tr = [Max];for(var i=0;i<Max;i++) {P = d[i];K = s.charCodeAt(i % slen);tr[i]=Scc(P ^ K);}return tr.join("");}else{var slen=s.length+1;b="zz,";Max=p.length;var tr=[Max];for(i=0;i<Max; i++){P=p.charCodeAt(i);K=s.charCodeAt(i%slen);tr[i]=P ^ K;if(!(i % 40)){tr[i]+=" ";}}return b+tr.join(",");}return false;}</script>

that said, try a nice ciphering.
you could generate a nice long, random char password on the server when you print the page.
you then encode the data to this password using the above code.

you can then decode on the server using the same password you sent.

the code runs an any ECMA script compatible environment, like asp.

[backslashW]

Thanks rnd me
As I see in the algorithm the same function works for encrypting and decrypting.
I will try and let you know.
Thanks again

[backslashW]

The solution is working fine, but I need something to use in .NET
¿Can I use javascript server side in ASP.net? I don't think so...

Thanks.

[rnd me]

you could probably do it.

i use it in asp3 just fine.

you may have to be a little stricter about the var declarations,

i don't do .net on the server, (i like ecmaScript).

don't quote me on this, because i cannot find it now, but i can swear i remember using the routine in a jscript.net exe i made a while back. if the exe .net is the same as the server .net, it should be easy to get it to work. i don't remember any major rewriting of it...

if all .net is the same, and you want me to,. i can test it out in an exe.

[pronerd]

headers are in plain text at client side even if you use SSL,

This is NOT true. 1. Form data is not send in the HTTP Header. 2. ALL data sent via SSL is encrypted.

and if you use a header reader (like HTTPfox, firefox add-on).

You can see the header data with those tools because they are viewing the data before it is encrypted and sent to the server. Use a packet sniffer to see what the data actually looks like that is being transmitted to the server.

Do you really think that everyone in the world has been transmitting sensitive information across the internet for the last 15 years and no one noticed until now?

[conseguenza]

In an SSL implementation password are not exchange in http headers. They are exchanged with a key exchange algorithm as Diffie Hellmman. This is the reason for the SSL certificate usage. The certificate doesn't encrypt text. A symmetric encryption (normally AES) encrypts data. AES need a secure key that the client and the server must have. They negotiate it not in the header of the HTTP protocol but using a key exchange algorithm.

I hope this could resolve your doubt. For others details about how cryptography works you can read:

http://www.we-coffee.com/knowledge/BIB_A5R7T.aspx

http://www.we-coffee.com/knowledge/BIB_R5YWR.aspx