tracker issue : CF-4070214

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

Hash SHA-256 Number of Iterations Off-By-One

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): bobo beebop / bobo beebop (bobo beebop)

Created: 10/07/2015

Components: Documentation

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Win 2008 Server x64

Vote Count: 2

Problem Description:  256 hashes are off-by-one

Steps to Reproduce: Run the code below and verify the output.

Actual Result: 28A9F6705886314ABD5617F406B4AF653F870DBB4207BFB1018804BF5CFB66D3

Expected Result: FBC1A9F858EA9E177916964BD88C3D37B91A1E84412765E29950777F265C4B75

Any Workarounds: Decrease the number of iterations by 1.

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

Watson Bug ID:	4070214

External Customer Info:
External Company:  
External Customer Name: bobo beebop
External Customer Email:  
External Test Config: My Hardware and Environment details: Not applicable.

<!--- Incorrect.  This is actually doing 2 iterations. --->

<cfset cornedBeef = hash("foo bar", "SHA-256", "us-ascii", 1)> <!--- 28A9F6705886314ABD5617F406B4AF653F870DBB4207BFB1018804BF5CFB66D3 --->


<!--- Setting numIterations to 0 produces the result of 1 iteration.  --->

<cfset cornedBeef = hash("foo bar", "SHA-256", "us-ascii", 0)> <!--- FBC1A9F858EA9E177916964BD88C3D37B91A1E84412765E29950777F265C4B75 --->



  1. October 08, 2015 00:00:00: 1_hashTest.cfm
  2. October 08, 2015 00:00:00: 2_hashTest2.cfm


The discrepancy cropped up between a Lucee and ColdFusion environment. ColdFusion's hash function is doing one extra iteration. I compared the results with Lucee, node.js, and two online SHA-256 hashers (one of which is here:
Comment by External U.
5624 | October 07, 2015 01:23:22 PM GMT
Hi bobo, Can you please attach the repro code for the bug. Thanks!
Comment by S P.
5625 | October 07, 2015 11:00:05 PM GMT
I have ran sample test with sha-256 <cfscript> writeoutput(hash('pavankumar','sha-256')); </cfscript> The result is A92A8D0A9CDD4AF917C4BCEA0E3BE0BC62C2554E789DE9C533F70957F0FCFFDA And the converter you have also given the same result. Thanks, Pavan.
Comment by S V.
5626 | October 07, 2015 11:38:16 PM GMT
S Preethi, The code has been attached, although the reproducing code was originally added in the Test Configuration section (it's only a few lines). I updated the test to include Paven's case. Paven, The code you posted is not the same as the code I added to my post; you don't have the numIterations parameter specified. The bug report pertains to the numIterations parameter. You're correct that when not providing the numIterations parameter the output is as expected. However, if the numIterations parameter is provided the output is off by one (it's one too high). Specifying 1 iteration should yield the same result as Pavan's test. It does not, however. Specifying 0 iterations results in the same output as Pavan's test. Giving 0 as the number of iterations makes no sense. It would only make sense if the parameter was the number of _additoinal_ iterations.
Comment by External U.
5627 | October 08, 2015 12:48:57 AM GMT
A gist with the original code can be seen and run here:
Comment by External U.
5628 | October 08, 2015 01:05:39 AM GMT
Hi Bobo, Coldfusion considers the number of iterations after hashing the given value whereas lucee considers the number of iterations before hashing the given value. Changing this behavior will break the existing code. Thanks, Pavan.
Comment by S V.
5629 | October 08, 2015 05:36:45 AM GMT
Hi Pavan, Right, that's what I suspected. Changing the behavior would indeed break existing code, mine included. That said, given the way that the function is defined in the documentation the behavior is erroneous. I would suggest a change in the documentation. 1) numIterations should be changed to numAdditionalIterations. 2) The documentation should reflect that this parameter is the number of iterations + 1; the number of additional iterations. 3) The documentation should reflect that the default number of additional iterations is 0. Right now I think that most would assume numIterations would default to 1. 0 iterations doesn't make sense. Presently it's quite confusing trying to get a consistent hash between two platforms, such as ColdFusion and, ColdFusion and .net, or even ColdFusion and Lucee. In all three cases ColdFusion diverges from the norm. Thank you for your time, -b
Comment by External U.
5630 | October 08, 2015 08:02:16 AM GMT
Voting for the documentation change. The way CF has done this defies logic a bit, but I guess we're stuck with it now.
Vote by External U.
5640 | October 08, 2015 08:25:40 AM GMT
+1 - The doc should rename the parameter to "reIterations"(?) and specify that it is the number of times to "re-iterate" and that the default value is 0. Leaving the parameter named as "iterations", and not specifying the default, is just asking for confusion.
Vote by External U.
5641 | October 09, 2015 10:11:06 PM GMT
The documentation regarding the same has been updated. Hence closing the bug. Thanks!
Comment by S P.
5631 | November 12, 2015 06:04:55 AM GMT
What is the change here: I do not see any text in there that clarifies this situation..?
Comment by External U.
5632 | November 13, 2015 08:55:01 AM GMT
Ditto. I don't see any change in the ColdFusion 10 online documentation. Where was this "fixed?"
Comment by External U.
5633 | November 14, 2015 01:43:35 PM GMT
Ditto. Hi Preethi, The documentation was not changed, or the change is not public. Can you please check? Thanks!, -Aaron
Comment by External U.
5634 | November 15, 2015 05:15:26 AM GMT
Please find the changes in the documentation at the below provided link: Thanks!
Comment by S P.
5635 | November 16, 2015 12:13:12 AM GMT
Hi Preethi, That link throws the following error: -------------------------------------------- Access Denied You don't have permission to access "" on this server. Reference #18.c4ef3e17.DVAPR-1447652933.67166b8 -------------------------------------------- I see "" in the URL which leads me to believe the change is not public yet? Thanks!, -Aaron
Comment by External U.
5636 | November 16, 2015 12:20:11 AM GMT
And if the changes are only on staging, the issue is not FIXED, it's just IN TESTING.
Comment by External U.
5637 | November 16, 2015 01:07:07 AM GMT
Update available in iterations parameter table here:
Comment by Jacob J.
5638 | November 16, 2015 01:37:48 AM GMT
That's better: cheers.
Comment by External U.
5639 | November 16, 2015 01:46:58 AM GMT