Are there any asymmetric encryption options for JavaScript?

Question

I have to transfer some sensitive information over a JavaScript AJAX Call, over an unencrypted channel (HTTP, not HTTPS).

I\'d like to encrypt the data, but encrypti

Answer 1

Are the Server > JavaScript messages sent over HTTPS?

If not, nothing prevents a man in the middle from changing the scripts. Any encryption will be useless if the code that has access to the unencrypted data is compromised.

Answer 2

I've done it. I use this JavaScript client-side asymetric RSA encryption to prevent the login credentials to be send in plain text over HTTP.

The goal is to prevent login request replay attacks based on network sniffing. Of course, this is not as secure as HTTPS since it would not resist to man-in-the-middle attacks, but it can be sufficient for local networks.

The client-side encryption uses Travis Tridwell's excellent work which is based on JSBN. Travis' web page can also generate the private and public RSA keys (if you are too lazy to use openssl). The keys are generated in PKCS#1 PEM format. I encrypt username+password+timeInMs+timezone so that the encrypted content changes at each login.

On the server-side, my Java code read read the PKCS#1 PEM file using Apache JMeter's org.apache.jmeter.protocol.oauth.sampler.PrivateKeyReader :

PrivateKey pk = (new PrivateKeyReader("myPrivateKeyFile.pem")).getPrivateKey();

Then I decrypt the encrypted content using

byte[] enc = DatatypeConverter.parseBase64Binary(clientData);
Cipher rsa = Cipher.getInstance("RSA");
rsa.init(Cipher.DECRYPT_MODE, pk);
byte[] dec = rsa.doFinal(enc);
String out = new String(dec, "UTF8");

Then I check if the client-side timestamp/timezone match the server-side timestamp/timezone. If the delay is less than a few seconds, the login process continues. Otherwise the request is considered a replay attack and the login fails.

Answer 3

asymmetric public key/ private key is the only way to do this. To protect against MIM attacks the server can hash the public key with the users password, then the user (in the browser) re-computes the hash - if they match then the user can be confident that the public key sent from the server has not been tampered with - this relies on the fact that only the server and the user know the users password.

PS I wanted to write this as a comment as that would be more appropiate than an answer, but I don't have enough points :)

See:openpgp.js for examples

Answer 4

This question seems to have what you're after, Javascript cryptography library to sign form data in browser The PGP link: http://www.hanewin.net/encrypt/ has RSA

Answer 5

The reason why you need encryption at all is probably to protect against a man-in-the-middle. There are scenarios where an attacker is able to sniff at the traffic without being able to change it. This solution would protect against that threat, but it would provide no protection at all against a man-in-the-middle that is able to modify the traffic.

If the attacker can change the traffic, then he will also be able to change the script that does the encryption. The easiest attack would be to just remove the encryption completely from the script. If you don't have https, and a man-in-the-middle is possible (which is the case in almost every scenario) then you don't have any control at all over the html or javascript that is presented to the end user. The attacker may rewrite your html code and javascript completely, disablign encryption, creating new form fields in your form etc. Https is a prerequisite for secure communication in the web-channel.