tracker issue : CF-3792283

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

Calling Randomize() with the SHA1PRNG does not create "repeatable number patterns".

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Robert Dong / Robert Dong (Robert Dong)

Created: 07/21/2014

Components: Language

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final / CF11 Update5,CF10 Update16

Priority/Frequency: Major / All users will encounter

Locale/System: English / Win 2008 Server R2 64 bit

Vote Count: 2

Listed in the version Issues Fixed doc
Problem Description:
Calling Randomize() with the SHA1PRNG does not create "repeatable number patterns" with the random number functions as the documentation states it should.  i.e. If I give Randomize() the same seed, I would expect the same number pattern to be returned from calls to Rand().

This is broken in CF10.  When tested in CF7 it worked fine.

Steps to Reproduce:
The example in the Randomize() documentation doesn't work as expected:

Actual Result:
In the example, when you keep providing the same seed to it, it keeps returning different random numbers in CF10.

Expected Result:
In the example, (as in CF7) when you keep providing the same seed to it, it should return the same random numbers on each invocation.

Any Workarounds:
The Randomize() function works as expected when not using the SHA1PRNG.

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

Watson Bug ID:	3792283

External Customer Info:
External Company:  
External Customer Name: CorporateRewards
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows Server 2008 R2 64-bit

ColdFusion 10,0,13,287689 Standard



In CF10, the IBMSecureRandom algorithm also has the same issue. Only the CFMX_COMPAT algorithm gives "repeatable number patterns".
Comment by External U.
11549 | July 21, 2014 11:01:44 AM GMT
Even the example provided in the documentation does not work.
Vote by External U.
11562 | July 21, 2014 11:33:05 AM GMT
It's a regression so should be fixed. Doesn't look like you guys have appropriate unit/regression test coverage here... theer's no way this should have got past you. NB: neither rand() nor randRange() respect the randomize() seeding. -- Adam
Vote by External U.
11563 | July 22, 2014 01:43:04 AM GMT
Attn @Ryall: I've updated the docs to reflect a) there being a bug; b) using an example that is cruft-free and *actually works*. -- Adam
Comment by External U.
11550 | July 22, 2014 02:22:24 AM GMT
For reference, the original example with the bug before Adam updated the docs can be found on . This example in these older docs still has the bug when run under CF10.
Comment by External U.
11551 | July 22, 2014 08:55:23 AM GMT
The documented behavior of randomize is only applicable to CFMX_COMPAT and non-secure PRNG algorithms. A secure random generation algorithm would not repeat the sequence as the randomness depends on lot of things other than the seed. This is not a bug.
Comment by Rupesh K.
11552 | August 04, 2014 11:55:34 AM GMT
Rupesh, can you pls clarify two things: a) based on what you say below... how come this all USED TO work as described on CFMX7, but now doesn't on CF10+? b) how is it "fixed" if there was nothing to fix?
Comment by External U.
11553 | February 12, 2015 03:14:09 PM GMT
(sorry, meant to add "cheers" to that before pressing send. It was a request, not a demand ;-)
Comment by External U.
11554 | February 12, 2015 03:17:41 PM GMT
I was earlier wrong. According to Wikipedia “A PRNG can be started from an arbitrary initial state using a seed state. It will always produce the same sequence when initialized with that state.” Since SecureRandom object creation is quite expensive, we started caching its instance from CF 9 onwards and that caused it to break. The fix is not to use the cached object for Randomize(). The fix would be available in the CF11 update 5 and CF10 update 16.
Comment by Rupesh K.
11555 | February 12, 2015 11:18:10 PM GMT
Oh right. I think I had that discussion with someone else on a different ticket, too. When you change direction on a ticket, can you PLEASE update the ticket to explain it. I seem to spend a lot of time going "can you pls clarify what's going on here?", because you lot aren't great at keeping us up to date with how you're handling a ticket. Cheers. -- Adam
Comment by External U.
11556 | February 12, 2015 11:53:52 PM GMT
The fix for this bug is available in the pre-release build of ColdFusion 11 Update 5 and ColdFusion 10 Update 16
Comment by CFwatson U.
11557 | February 20, 2015 09:26:27 AM GMT
Updated content here:
Comment by Jacob J.
11558 | March 30, 2015 06:48:36 AM GMT
Hi Rupesh, In CF11 Update 5 (build 11,0,05,293506), randomize(12345, "SHA1PRNG") does not ensure repeatable number patterns even w/ JVM arg -Dcoldfusion.disablejsafe=false on developer edition. Should it? BTW, that documented argument seems wrong for "disabling JSAFE". It seems the argument to disable JSAFE should be -Dcoldfusion.disablejsafe=true. However, I tried that as well and still no repeatable number pattern. Thanks!, -Aaron
Comment by External U.
11559 | November 20, 2015 06:16:35 AM GMT
Hi Aaron, Yes, the value of the flag should be true. I have updated the documentation. I have tried the below example having the jsafe flag in place. <cfset mySeedInt = 12345> <cfset Randomize(mySeedInt, "SHA1PRNG")> <cfoutput> rand(): #rand("SHA1PRNG")#<br> rand(): #rand("SHA1PRNG")#<br> rand(): #rand("SHA1PRNG")#<br> </cfoutput> And each run giving me the same (repeatable with the given seed) pattern. Please provide the example you are trying. Thanks, Pavan.
Comment by S V.
11560 | November 20, 2015 06:50:59 AM GMT
Hi Pavan, Sorry, my code was wrong. I had rand() instead of rand("SHA1PRNG"). Basically, I hadn't checked the rand() doc for proper syntax. =P I see your code runs fine on CF11U5 w/ -Dcoldfusion.disablejsafe=true. Thanks for updating the JVM arg in the doc, that was fast! Thanks, -Aaron
Comment by External U.
11561 | November 20, 2015 07:51:46 AM GMT