tracker issue : CF-3842326

select a category, or use search below
(searches all categories and all time range)
Title:

encrypt() key passed as a string vs. as a variable renders a different result

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Aleksey Ivanov / Aleksey Ivanov (midimaxi)

Created: 10/22/2014

Components: Language

Versions: 9.0.1

Failure Type:

Found In Build/Fixed In Build: 9.0.1 / CF11 Update5

Priority/Frequency: Major / All users will encounter

Locale/System: English / Windows 7

Vote Count: 0

Listed in the version 11.0.05.293506 Issues Fixed doc 
Problem Description:when passing a secret to encrypt() function as a variable, the encrypted string changes on every request. 

Steps to Reproduce: 
<cfset secretKey = "Hq/WFySQfzQsO0mp2ixJDA==" />
<cfset encStr = encrypt("someText", secretKey,"AES/CBC/PKCS5Padding","hex") >
<cfset decStr = decrypt(encStr, secretKey, "AES/CBC/PKCS5Padding","hex") >
<cfoutput>#encStr#</cfoutput>
<cfoutput>#decStr#</cfoutput>

vs.

<cfset encStr = encrypt("someText", "Hq/WFySQfzQsO0mp2ixJDA==","AES/CBC/PKCS5Padding","hex") >
<cfset decStr = decrypt(encStr, "Hq/WFySQfzQsO0mp2ixJDA==", "AES/CBC/PKCS5Padding","hex") >
<cfoutput>#encStr#</cfoutput>
<cfoutput>#decStr#</cfoutput>

Actual Result: When key is passed as a variable, encrypted string changes on every request. When key is explicitly provided, encrypted string does not change.

Expected Result:

Any Workarounds:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3842326

External Customer Info:
External Company:  
External Customer Name: midimaxi
External Customer Email:  
External Test Config: My Hardware and Environment details: Windows 7, IIS7, CF9.0.1

Attachments:

Comments:

Some extra notes: In testing I was able to Decrypt EITHER encrypted string with the variable (or vice versa). So to be clear this does not impact the decryption of the encrypted string. A hash is subject to comparison with an identically hashed string, but I'm wondering if that should be the case for encrpytion. Wouldn't you always decrypt for comparison? In which case is this a bug? Not sure on that. Repeated testing shows that the encrypted string passed the variable DOES change with each request. Meanwhile, the one passed the string directly does not change but remains static - the same encrypted string as the result every time.
Comment by External U.
10526 | October 29, 2014 11:41:38 AM GMT
It does not impact encryption/decryption, it impacts output from encryption based on how you pass the key. Encrypted string change if you pass key as string literal and does not change if you pass it as a variable.
Comment by External U.
10527 | October 29, 2014 12:39:58 PM GMT
My Analysis: This is happening because of a coldfusion compiler optimization. If all the arguments for a function are explicitly specified (no variables) and the function is marked as static (we call it internally) the function is executed once and the result will be directly hardcoded into the compiled unit of cfm page. cipher mode CBC requires an IV for an encryption operation. If IV is not supplied for the encrypt function ColdFusion generates a random IV uses it for encryption, also prefixes the encrypted output with this IV so that it can be used during decryption. In the first case the function contains a variable so the function gets executed every time generates a new IV thereby produces a different string (but a valid encrypted string). In the second case because of the compiler optimization it executes only once and gives the same encrypted string each and every time. But as you said it does not impact encryption/decryption.
Comment by S V.
10528 | October 30, 2014 05:54:06 AM GMT
Also, in case of hashing like SHA1 it will always generate a unique string. So this is not a bug.
Comment by S V.
10529 | October 30, 2014 06:07:05 AM GMT
If it's *supposed* to generate a different value every time and the second version doesn't (because of your over-eager compiler "optimisation"), then that is a BUG. Perhaps different from the one that was raised, but it's a bug. -- Adam
Comment by External U.
10530 | October 30, 2014 04:49:09 PM GMT
Also if any CFML code behaves differently if code uses a variable or a literal with the same value... that's a bug too. -- Adam
Comment by External U.
10531 | October 30, 2014 04:50:32 PM GMT
I think you guys have it narrowed down but Adam's point is correct I think. If, in the case of the variable, it generates random IV and thus produces a different string each time - and you are saying that is the proper behavior (and I have no reason to doubt you), then the second case - where the encryption operation ALWAYS produces an IDENTICAL string when passed a string literal violates your claim of the first case being the proper behavior. It should EITHER produce an identical string in both cases OR a unique string in both cases. To have both behaviors is, I think unpredictable and "buggy" in some way or another. Having said that, as I said below - it's customary to decrypt an encrypted string in order to compare it, so I'm ok with this being a low priority. Still, you should recognize one behavior or the other - or am I missing something?
Comment by External U.
10532 | October 30, 2014 05:23:41 PM GMT
Fix verified.Will be available in the next release.
Comment by S P.
10533 | December 22, 2014 08:17:46 AM GMT
The fix for this bug is available in the pre-release build of ColdFusion 11 Update 5
Comment by CFwatson U.
10534 | February 20, 2015 09:26:51 AM GMT
Verified this is fixed in CF11 Update 5 (build 11,0,05,293506). A win for consistency. I do always find it interesting when engine behavior (or engine swapping - as was the case w/ JRun-to-Tomcat) is used as justification as to if a ticket is a bug or not. Internals shouldn't leak out. Thanks!, -Aaron
Comment by External U.
10535 | November 21, 2015 06:48:35 AM GMT