decrypt issue

[rickmaz]

I have an application client side both in php and cf code which does simliar things. Both post to cf server 2021 upadate 18. i believe the update 18 is cuasing the issue but i would have to roll back to 17 to test this. In my logs everything was fine until 2/20/2025 and in my installer downloads on the CF server i see on 2/19 i downloaded update 18 so i assume it was intalled on the 19th or early on 20th of feb. Every since then I have the problem. I am not 100% certain that is the issue but if that makes sense to anyone let me know. Now for the issue. To be clear If i encrypt on a CF server which front end app is (also update 18) and then decrpt on 2nd CF server update 18th this still works even after update 18 installed on 2/20. My issue is with PHP front end. I am encrypting with php page and posting to cf server (same one as the cf front end app) and this now does not work. Both php and cf front end worked fine before update 18. 

For Cf front end i am using basic: function encryptData(data) {
var encryptionKey = generateEncryptionKey();
var jsonData = serializeJSON(data);
var encryptedString = encrypt(jsonData, encryptionKey, "AES", "hex");
return encryptedString;
}

on backend to decypt i am using: function decryptData(encryptedString, accountID, secretKey) {
var encryptionKey = generateEncryptionKey(accountID, secretKey);
var decryptedJSON = decrypt(encryptedString, encryptionKey, "AES", "hex");
return deserializeJSON(decryptedJSON);
}

this seems to work. BUT if i send encryption using this function on php to encrypt: function encryptForReauthenticationWC($data, $client) {
try {
$keyBytes = base64_decode($client['encryption_key']);
$ivBytes = base64_decode($client['iv']);

// Ensure data is UTF-8 encoded
$dataBytes = mb_convert_encoding($data, 'UTF-8');

// Apply PKCS7 padding manually
$blockSize = 16;
$padSize = $blockSize - (strlen($dataBytes) % $blockSize);
$dataBytes .= str_repeat(chr($padSize), $padSize);

$encryptedBytes = openssl_encrypt($dataBytes, 'AES-256-CBC', $keyBytes, OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING, $ivBytes);
$encryptedData = customUrlEncode($encryptedBytes);

logMessage_check("Custom encoded data length: " . strlen($encryptedData), $client);
return $encryptedData;
} catch (Exception $e) {
logMessage_check("Encryption failed: " . $e->getMessage(), $client);
return "";
}
} 

the decryption fails i have a failver on the backend if the normal decrypt data function does not work to try this way: <cfif NOT isDecrypted>
<cftry>
<!--- Decode the custom encoded data --->
<cfset customEncodedData = url.data>
<cfset base64EncodedData = replace(replace(replace(customEncodedData, '-', '+', 'all'), '_', '/', 'all'), ',', '=', 'all')>
<cfset encryptedBytes = binaryDecode(base64EncodedData, "base64")>

<!--- Log received data info --->
<cflog file="check_api_auth_log" text="Received data length: #len(customEncodedData)#" type="information">
<cflog file="check_api_auth_log" text="Decoded data length: #arrayLen(encryptedBytes)#" type="information">


<!--- Decode the Base64 encryption key and IV --->
<cfset keyBytes = binaryDecode(clientDetails.encryption_key, "base64")>
<cfset ivBytes = binaryDecode(clientDetails.iv, "base64")>

<!--- Create SecretKeySpec and IvParameterSpec --->
<cfset secretKeySpec = createObject("java", "javax.crypto.spec.SecretKeySpec").init(keyBytes, "AES")>
<cfset ivParameterSpec = createObject("java", "javax.crypto.spec.IvParameterSpec").init(ivBytes)>

<!--- Create Cipher instance --->
<cfset cipher = createObject("java", "javax.crypto.Cipher").getInstance("AES/CBC/PKCS7Padding")>

<!--- Initialize cipher for decryption --->
<cfset cipher.init(cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec)>

<cfset decryptedBytes = cipher.doFinal(encryptedBytes)>
<cfset decryptedString = toString(decryptedBytes, "UTF-8")>


<!--- Log decrypted data info --->
<cflog file="check_api_auth_log" text="Decrypted data length: #len(decryptedString)#" type="information">

<!-- Parse the decrypted string into a struct -->
<cfset decryptedParts = listToArray(decryptedString, "|")>
<cfset decryptedData = {
userID: decryptedParts[1],
timestamp: decryptedParts[2]
}>
<cfset isDecrypted = true>
<cfcatch>
<cflog file="check_api_auth_log" text="Error: WC re-authentication decryption failed. Error: #cfcatch.message#" type="error">
<cfoutput>Error: Invalid verification data.</cfoutput>
<cfabort>
</cfcatch>
</cftry>
</cfif>
In my logs for the php attempt the log error i am seeing is Error: cannot fine any provider supporting AES/CBC/PKCS7Padding

neither work and it completely fails. AGain all worked before update 18 I can try to roll back unless someone can see something obvious but of course I would like to solve it becuase it all worked before update 18 and i need to upate at some point. Thanks in advance

[Charlie Arehart]

Let me first help others looking at this by noting that he shows using an encryption algorithm ("aes") for his encrypt and decrypt functions in cfml, so this not about the change introduced by the June 2024 cf update (u14 of his cf2021). So there would seem to be another explanation. 

It seems you're saying the error is on the code doing this:

<cfset cipher = createObject("java", "javax.crypto.Cipher").getInstance("AES/CBC/PKCS7Padding")>

... as that's what's using the "AES/CBC/PKCS7Padding" that your error is reporting. That createObject call is pointing to a class that Cf will be finding in some jar, somewhere on its classpath. We can't know. But you're thinking "update 18 must have changed it". 

But I will be VERY surprised if that's so. Update 18 was an update SOLELY about the pmt agent (cf's built-in monitoring solution), having nothing to do with encryption--that I know of. 

So first, yes, you could try rolling back to update 17. If that worked, it may seem to prove your point that "18 broke it".

But it may also be that either update 18 OR 17 had a failure in the update, and in that case it's not clear if either "worked", and so we could not blame either--if the update failed. And you can view that (without uninstalling the update) by viewing the update install log, found within the hf-updates folder under the instance, likely cfusion. Look at about line 70 for the count of any fatalerrors or no fatal errors, for both update 18 and 17. 

Let us know what you find, or if you try the uninstall, or if you learn anything else. Or maybe someone else will have a different suggestion.

[Brian__]

I agree with @Charlie Arehart that CF2021U18 is unlikely to be the reason for this not working.  I don't have a complete solution, but I have a few observations that might put you on the right track - 

1) The javax.crypto.Cipher class doesn't appear to support PKCS7Padding - see https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/Cipher.html.  

But PKCS7Padding and PKCS5Padding are practically the same -- PKCS5Padding is for ciphers that have a blocksize of 8 bytes, and PKCS7Padding can support a variable blocksize between 1 and 255 bytes.  (AES has a blocksize of 16 bytes, but since 16 is a multiple of 8, PKCS5Padding works fine with AES.)

But when I change your code to:

<cfset cipher = createObject("java", "javax.crypto.Cipher").getInstance("AES/CBC/PKCS5Padding")>

I get the following erorr:

The init method was not found

Is there a reason you're using the javax.crypto.Cipher class here instead of ColdFusion's native encrypt()/decrypt() functions?

2)  encrypt(jsonData, encryptionKey, "AES", "hex"); will use AES in ECB mode, but your other code uses AES in CBC mode.

After the updates in APSB24-41 from June 2024, 'AES/CBC/PKCS5Padding' is the default alogoithm (i.e., if you call encrypt()/decrypt() without specifying an algorithm), but ECB is still the default mode of operation if you explicitly specify "AES" as the algorithm with no other options.

I don't know what your expected program flow is, but it looks like you are using two different encryption/decryption configurations.

[rickmaz]

i dont know either but i can tell you I have the app installed on 6 different linux servers php 7 and 8 encrypting the exact same way, 7-10 a day since august -- the code did not change on encryption side -- The EXACT day i installed update 18 that code stopped working. I can only guess maybe something that should not have worked before did and Adobe cleaned it up, forgot to document it or just decided not to since it was something technically that should not have worked in some versions? I dont know. I had to recode theentire thing to get it to work but now it does yes using different method. I just dont understand why things break liek this. I go out of my way to look at the release notes before the upgrades and try to test but its all good. I think you for the replies as it helped me know where to look or what to maybe eliminate. 

[Brian__]

In that case, I'm stumped! 🙂 

[BKBK]

Do you make use of ColdFusion's Performance Monitoring Toolset (PMT)? I ask because Update 18 is about a vulnerability connected with PMT. That suggests an idea: to go one step further to eliminate Update 18 as the cause of the issue. 

Let's assume you're NOT using PMT. Then you could try to resolve the issue by uninstalling the PMT package and by applying one of the mitigating actions that Adobe recommends for Update 18.

The steps would be:

1.  With Update 18 still installed,  make the following changes in the ColdFusion Administrator. Navigate to Package Manager > Packages > Installed Packages. Click on pmtagent, then on the Uninstall button.
2.  Add the flag -Dcoldfusion.monitoring.id.reset=false to the java.args property in jvm.config.
3.  Restart ColdFusion.

[BKBK]

Hi @rickmaz , another suggestion.

It is unclear to me why you use the Bitwise-Or in

$encryptedBytes = openssl_encrypt($dataBytes, 'AES-256-CBC', $keyBytes, OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING, $ivBytes);

 What about doing it like this instead:

$encryptedBytes = openssl_encrypt($dataBytes, 'AES-256-CBC', $keyBytes, $options=OPENSSL_RAW_DATA, $ivBytes);

[rickmaz]

Its a good point. I do this in another php function (or similar) . I think
when I built this page I was having issues with coding on the CF side this
was decrypting against so i did this and somehow got it to work. As I
mentioned, it has been so again something changed but your suggestion is
definitely better so I am going to test and implement that 🙂 Thank you!

[Brian__]

I'm already a little out of my depth, but I'll take one more wild guess.  I see that the Java BouncyCastle API does support PKCS7Padding.  Is there any chance that your JRE/JDK versions or configuration changed at the same time as you upgraded to CF2021U18?  I think security/crypto providers will be defined in the "security.providers" settings in $JAVA_HOME/jre/lib/security/java.security (or similar).  It doesn't look like a JRE update would come with CF2021U18, but if your JRE config did change, that could be a reason why the behavior of your Java-native crypto functions changed.

[rickmaz]

I literally did not change anything, the code was the same, java the same,
cf version the same. This code was working from March of last year until
feb 20th the day i installed update 18. It could be that my code was not
optimized and Adobe made some cleanup changes or something else minor and
maybe my code should have been better all along but all I know is what I am
reporting. The only time I made changes to my java config was for some CF
updates for COMPAT and things liek that to allow them. I was able to fix
it. I just wish they would document ALL changes.

[BKBK]

@rickmaz , Did you implement the PMT tip I suggested?

[BKBK]

...I just wish they would document ALL changes.

By @rickmaz

Wise words indeed. .

In fact, that got me thinking along the same lines as @Brian__ . What Java version does your ColdFusion 2021 installation run on? Might it be that your Java version differs from the one the Adobe team used when developing Update 18?

For example, most installations continue to use the Java version that ships with ColdFusion 2021, namely, 11.0.11. But the current Java version available to ColdFusion 2021 is 11.0.26. Some of the Java 11 releases since 11.0.11 include changes that involve encryption (for example, 11.0.12).

[rickmaz]

I am running 11.0.25. I did update it at some point but I'm not sure if
there is any way to know when I did that update? i definitely did it before
the 18 update and it was working but yes they could have updated something
in 18 testing on .11 java and all looked good. that would make sense I
suppose.

[BKBK]

If your code worked before on Java 11.0.25, then it is unlikely that the Java version is the culprit. Again, could you please do the test I suggested regarding the Performance Monitoring Toolset (PMT). Just for the purposes of elimination. 

[BKBK]

Looking elsewhere, my attention is again directed to padding in the PHP code. I mentioned earlier my doubts about the choice between $options=OPENSSL_RAW_DATA and $options=OPENSSL_ZERO_PADDING. Now, I am thinking: what if you leave these out altogether?

That is, what if you leave it up to PHP to use its default? Something like this:

function encryptForReauthenticationWC($data, $client) {
    try {
        $keyBytes = base64_decode($client['encryption_key']);
        $ivBytes = base64_decode($client['iv']);

        // Ensure data is UTF-8 encoded
        $dataBytes = mb_convert_encoding($data, 'UTF-8');

        // Encrypt using OpenSSL (NO manual padding)
        $encryptedBytes = openssl_encrypt($dataBytes, 'AES-256-CBC', $keyBytes, 0, $ivBytes);
        
        if ($encryptedBytes === false) {
            throw new Exception("OpenSSL encryption failed: " . openssl_error_string());
        }

        $encryptedData = customUrlEncode($encryptedBytes);

        logMessage_check("Custom encoded data length: " . strlen($encryptedData), $client);
        return $encryptedData;
    } 
    catch (Exception $e) {
        logMessage_check("Encryption failed: " . $e->getMessage(), $client);
        return "";
    }
}

[BKBK]

Now, on to the CFML code. I agree with @Brian__ that you should experiment by replacing 

<cfset cipher = createObject("java", "javax.crypto.Cipher").getInstance("AES/CBC/PKCS7Padding")>

with

<cfset cipher = createObject("java", "javax.crypto.Cipher").getInstance("AES/CBC/PKCS5Padding")>

In addition, ColdFusion's toString() method might be too blunt an instrument to use to convert a byteArray to a string. I say this because its first argument can be one of any number of objects. To be more specific, use an instance of the Java String class instead.

Hence,

<cfset decryptedString = createObject("java", "java.lang.String").init(decryptedBytes, "UTF-8")>

in place of

<cfset decryptedString = toString(decryptedBytes, "UTF-8")>

[Charlie Arehart]

Yep, excellent point there, Brian. And while that's part of what I was getting at in my original reply (about the createObject call to that Cipher class, and how I'd not have expected the cfupdate alone to affect that).

More specifically (and to confirm your question), no, a cf update does not typically (I daresay does not ever) update the jvm cf uses.

So yes, if that jvm changed with the update, that might explain it. Or he or someone may have implemented a new bouncycastle jar at the same time. 

Finally, I was also suggesting that his previous update may have failed, in which case some other aspect of the last update "worked"--which would then change MORE than what a "normal" update from 17 to 18 would do. I recommended how Rick could confirm that, but I don't see he ever replied. I realize other answers can seem more compelling--or less arduous. 🙂

Let's see if yours might be just the ticket for him. 🙂 

[Charlie Arehart]

To be clear, I was writing my last reply to Brian at the same time Rick was writing his--but I was taking longer, which is why mine appears after Rick's.