4

In my project (Titanium Appcelerator Android mobile App) I am using the CryptoJS library to encode with AES.

Although the first time that the CryptoJS.AES.encrypt is used it does not have any salt (i printed the salt of the encrypted variable and it says 'undefined'), all the others from this and on have random salts.

Here is some code:

var key53 = CryptoJS2.enc.Base64.parse("ASTRING");
var iv53  = CryptoJS2.enc.Base64.parse("ANOTHERSTRING");

var encrypted1 = CryptoJS2.AES.encrypt(String("test"), String(key53), {iv: String(iv53)});
var encrypted2 = CryptoJS2.AES.encrypt(String("test"), String(key53), {iv: String(iv53)});
/* other code here */
var encrypted3 = CryptoJS2.AES.encrypt(String("test"), String(key53), {iv: String(iv53)});
alert(encrypted1.salt);       // undefined
alert(encrypted2.salt);       // undefined
alert(encrypted3.salt);       // some random salt

Then I am using Coldfusion to decrypt these encrypted values, just like this:

<cfset base64Key = "ASTRING">
<cfset base64IV = "ANOTHERSTRING">

<cfset ivBytes = binaryDecode(base64IV, "base64")>

#decrypt(variables.ename, base64Key, "AES/CBC/PKCS5Padding", "base64", ivBytes)#

When there is no salt involved, Coldfusion decrypts perfectly. However, when there is a salt, coldfusion throws this error:

An error occurred while trying to encrypt or decrypt your input string: Given final block not properly padded.

Thus, I would like my encryption to NOT involve any salt. Is this possible in CryptoJS? And if yes, HOW?

Thanks a million!

Michael M.
  • 63
  • 6
  • 1
    Not sure how you could get "undefined" there... It sounds like the same issue on [this thread](http://stackoverflow.com/questions/16600509/aes-encrypt-in-cryptojs-and-decrypt-in-coldfusion/16615194#16615194), ie When the key is passed as a *String* (like above), the value is treated as a passphrase that is used to derive both key and IV randomly. However, if you pass it as a "WordArray" you get the expected results: `CryptoJS.AES.encrypt(String("test"), key53, {iv: iv53})`. Note, be sure to use a [random IV](https://en.wikipedia.org/wiki/Initialization_vector). – Leigh Nov 18 '15 at 03:43
  • @Leigh That seems to be the answer. Care to post it as one? – Artjom B. Nov 18 '15 at 08:15
  • @Leigh Thank you very much for taking the time to explain to me what I am actually doing wrong there. Could you possibly post it as an answer? I would be more than happy to flag it as a correct one. – Michael M. Nov 18 '15 at 12:33
  • Also, could you please, explain why I need to use a random IV and how can the server know it beforehand since it will be random? – Michael M. Nov 18 '15 at 12:34
  • Reusing the same iv can leak information about the encrypted value. See [Initialization vectors](https://helpx.adobe.com/coldfusion/kb/strong-encryption-coldfusion-mx-7.html) and http://crypto.stackexchange.com/questions/10505/reusing-keys-with-aes-cbc and https://en.wikipedia.org/wiki/Initialization_vector – Leigh Nov 18 '15 at 14:37
  • @MichaelM. The IV can be prefixed to the ciphertext, or send any other way. The IV must be indistinguishable from random to an attacker, but it may be send in the clear. Note that CBC encoding itself is not secure for transport security, you need an authentication tag as well, otherwise anybody can alter and even decipher your ciphertext. – Maarten Bodewes Nov 18 '15 at 17:48
  • Thanks a lot Leigh and @Maarten Bodewes. I am not very experienced in AES and CBC but I think I get it. However, I still find sending the IV (either pre/postfixed to the ciphertext or as a standalone string) seems not that secure too. I mean, if I was the attacker, I would try all the possible pre/postfixes and ciphertexts and "could" (it is possible to) decipher the ciphertext easier and faster than trying to find it from repeatable IV. – Michael M. Nov 18 '15 at 19:38
  • @MichaelM. - Well, you are not alone ;-) Take a look at some of the entries on crypto.stackexchange.com for more in depth explanations a nd discussions, such as http://crypto.stackexchange.com/questions/8809/using-aes-cbc-and-providing-the-iv-in-file-header-security-hole – Leigh Nov 18 '15 at 22:21
  • 1
    @Leigh The whole conversation has been really helpful! Thank you so much for your time. It really helped me get deeper into encryption coding. – Michael M. Nov 19 '15 at 11:11
  • @MichaelM. - BTW, in case you did not see the notes, I mentioned on the other thread, doing this on the client side does not sound at all secure... I would definitely ask around on crypto.stackexchange.com about how to handle keys securely when using a client side library like this. – Leigh Dec 02 '15 at 01:29

0 Answers0