AES Encrypt in CryptoJS and decrypt in Coldfusion

Question

We've got a Silent Login service written in Coldfusion9 that accepts encrypted strings from external systems and then decrypts based on an agreed Algorithm/Encoding setup. This has worked without issue for years now from systems running ASP/JAVA/PHP, but we now have a client who has no choice but to use CryptoJS to perform the encryption and for the life of me I cannot work out why this won't decrypt in Coldfusion.

My knowledge of encryption isn't brilliant but the thing I am noticing is the CryptoJS encrypted ciphertext for the exact same string/key differs every time i perform the encryption whereas in Coldfusion/Java i can always expect the exact same encrypted string. I'm not sure if this is encoding related or not but i've never run into this issue accepting encrypted strings from any other system before, so I am hoping it's the way I am encrypting in CryptoJS that is incorrect.

<cfoutput>

<!--- Set String and Key --->
<cfset theKey = toBase64("1234567812345678")>
<cfset string = "[email protected]">

<!--- CryptoJS AES Libraries --->
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/components/enc-base64-min.js"></script>

<script>

// Encrypt String using CryptoJS AES
var encrypted = CryptoJS.AES.encrypt("#string#", "#theKey#");
console.log(encrypted.toString());

// Decrypt String using CryptoJS AES 
var decrypted = CryptoJS.AES.decrypt(encrypted, "#theKey#");
console.log(decrypted.toString(CryptoJS.enc.Utf8));

</script>

<!--- Coldfusion Decrypt String / FAILS --->
Decrypted: #decrypt(encryptedEmail, "#theKey#", "AES", "BASE64")#

</cfoutput>

Solution

There seem to be two issues:

1. CryptoJS is not using your variable as the key. As @Miguel-F mentioned, when you pass in a string, "it's treated as a passphrase and used to derive [the] actual key and IV". Both are randomly generated, which is why your encrypted result keeps changing. But more importantly, this means that CryptoJS is using a completely different key than the one in your CF code and that is why decrypt() fails. (At least it is part of the reason ...)

2. The second problem is that in addition to the algorithm "AES", there are two other encryption settings which must match: mode and padding scheme. While CryptoJS and ColdFusion use the same defaults for padding scheme, the "modes" are different:

   • ColdFusion uses "ECB". "AES" is actually short for "AES/ECB/PKCS5Padding"
   • CryptoJS uses "CBC", which requires an additional iv (initialization vector) value.
     
     

You need to ensure all three settings are the same on both sides. Try using CBC mode in CF, since it is more secure than ECB anyway. Note: It requires adding an IV value.

CF Code:

<!--- this is the base64 encrypted value from CryptoJS ---> 
<cfset encrypted = "J2f66oiDpZkFlQu26BDKL6ZwgNwN7T3ixst4JtMyNIY=">
<cfset rawString = "[email protected]">
<cfset base64Key = "MTIzNDU2NzgxMjM0NTY3OA==">
<cfset base64IV = "EBESExQVFhcYGRobHB0eHw==">

<cfset ivBytes = binaryDecode(base64IV, "base64")>
<cfoutput>
    #decrypt(encrypted, base64Key, "AES/CBC/PKCS5Padding", "base64", ivBytes)#
</cfoutput>

CryptoJS: (Adjusted Original Example)

<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/components/enc-base64-min.js"></script>
<script>
    var text = "#rawString#";
    var key = CryptoJS.enc.Base64.parse("#base64Key#");
    var iv  = CryptoJS.enc.Base64.parse("#base64IV#");

    var encrypted = CryptoJS.AES.encrypt(text, key, {iv: iv});
    console.log(encrypted.toString());

    var decrypted = CryptoJS.AES.decrypt(encrypted, key, {iv: iv});
    console.log(decrypted.toString(CryptoJS.enc.Utf8));
</script>

Edit:

All that said, what do you mean by the client "has no choice but to use CryptoJS to perform the encryption"? Why cannot they use server side encryption? I am not an encryption expert, but doing encryption in javascript, and exposing the key on the client, does not sound wildly secure to begin with ...

Comments

[Miguel-F]

+1 @Leigh - I had been looking at it this morning (but then had to leave) and basically came to the same conclusion as you. Without all the same pieces ColdFusion will not be able to decrypt the value. I even wrote up a test script similar to what you have here but never did get it to decrypt correctly...

[Leigh]

Yeah, it usually something small like a difference like encoding, mode or padding. But with encryption that is all it takes to get a completely different result ;-) @Phil - For clarity's sake, you may want to set the CryptoJS mode and padding explicitly ie {iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7}. Just so it is clear.

[Leigh]

@Miguel-F - For grins I tried using the less secure ECB mode too. But had no luck with it. The docs say it is supported, but I am not so sure .. because they also say "If you pass the actual key, you must also pass the actual IV.". Given that ECB does not use an iv that does not make sense .. No great loss though, since CBC is better anyway.

[Miguel-F]

Funny that you say that because I was trying ECB mode. At least that makes me feel better that I could not get it to work. ;)

[Phil Rasmussen]

Thankyou so much for taking the time to write this answer Leigh worked like a charm and i learnt a little more about encryption in the process and the specific modes as I had never used CBC and the IV's before. Can i just confirm that the IV and Key you generated can be done with the Coldfusion GenerateSecretKey('AES') for both. I looks like an AES key but just wanted to confirm.

[Leigh]

Yes. As long as CryptoJS follows the specs for AES (which it appears to) the keys are interchangeable. Just keep in mind that doing anything client side is less secure, because you have to expose the data for it to work. In this case they key. So it seems a little like locking your house, but leaving the key taped to the front door.

[Leigh]

To generate iv values, see java's SecureRandom

[Rajeev]

@Leigh Is there anyway i can compress the string before encyption?

[Abhijeet]

Demo Link for the above source Code: Plnkr link : Look for browser console for result

[André C. Andersen]

Why does adding or removing a character from "#base64Key#" make this fail?

[Fergus]

or you can replace enc.Base64 with enc.Hex