# Encrypting data on client side and passing it to server side

I'm passing the data to PHP server side which will use the information later as this:

    <script> function encrypt() {
var salt = CryptoJS.lib.WordArray.random(128/8);
var key256Bits500Iterations = CryptoJS.PBKDF2("'.\$token.'", salt, { keySize: 256/32, iterations: 500 });
var iv  = CryptoJS.enc.Hex.parse("101112131415161718191a1b1c1d1e1f");
var data_base64 = encrypted.ciphertext.toString(CryptoJS.enc.Base64);
var key_base64  = encrypted.key.toString(CryptoJS.enc.Base64);
var iv_base64   = encrypted.iv.toString(CryptoJS.enc.Base64);
var data = {encrypted: data_base64, iv: iv_base64, key: key_base64};
return true;
} </script>


My question is, since I am passing this through the form as POST, that still can be sniffed with shark-like tools and then decrypted with all information being passed through anyways.

What information should be private and how should I make them private? How could they be private if the IV, data, and the key are being send through the POST that are needed when decrypting the string?

How is the logic here flawed and how should it be used to protect data communication between client and server side computing?

• Why not just use HTTPS? Nov 2, 2014 at 9:36
• Just providing basic security for small CMS. Case may be that HTTPS might not be available. If I could assure that I could use HTTPS every time, I definitely would use it. Thanks. Nov 2, 2014 at 11:41
• I'm thinking of using jcryption.org instead. Nov 2, 2014 at 11:42
• Note that without HTTPS, any JavaScript-based encryption is still vulnerable to man-in-the-middle attacks. A rogue wireless access point or ISP could serve a trojaned jcryption.js to the client and defeat the whole thing. Nov 2, 2014 at 17:36
• I wasn't aware, and thank you for pointing this out. But as Tim suggested using asynchronous encryption would be good-enough protection for this simple project when dealing protecting user data without having HTTPS on every page, which is costly. Nov 3, 2014 at 0:16

What information should be private?

The key should be private, everything else can be public (the iv, the source, etc).

How is the logic here flawed

You are using a symmetric key algorithm, which means that the same key decrypts and encrypts data, which in turn means that you would have to exchange the key between the parties (which would need to happen over a different channel, for example paper mail).

What you actually need is an asymmetric algorithm, which has a public key for encryption and a private key for decryption.

If you need to encrypt more data than showing here, you can use an asymmetric algorithm to exchange the key of a symmetric algorithm (as asymmetric encryption is unpractically slow). This is how HTTPS works, for example.

how should it be used to protect data communication between client and server side computing?

Use HTTPS. At the time, there really isn't an alternative for this. (well, you could use third party services such as OpenID). You definitely need asymmetric encryption, and you should definitely not write your own.

Misc

• either always use camelCase or always snake_case, don't mix them without reason.
• key256Bits500Iterations is quite descriptive, but I think key would be just fine as well, and easier to read (and what if you change it to 600 iterations? Either your name would be wrong, or you would need to change it).
• encrypt doesn't just encrypt, it also changes the form. I would to this in a different function and just let encrypt do the encrypting.
• wherever you do the form manipulation, you should also set document.loginForm.password1.value to something else right there.
• Thanks for your opinion. I do not have an access to SSL over HTTPS at this moment. I was looking into this and I think I'll use jCryption instead. Thank you for your words. Nov 2, 2014 at 11:40