Errors with encrypt/decrypt after CF7 to CF8 upgrade

It's definitely not a keyword, and I'm using straightforward encrypt(ssn,key) and decrypt(ssn,key).

Here's another oddity ... in a test table, I encrypted some of the social security numbers that I had on file, using the exact same encryption key in the exact same file, and the numbers decrypted just fine. I used SQL Server Comparison Tool to compare the encrypted SSNs in my original and test tables, and even though the comparison tool flagged the field content as different, the content looks to be identical. I re-entered data in another field to see if the comparison tool would flag it as different just because the content had been overwritten, but the tool read the data as identical. ???? I'm at a loss.

> the content looks to be identical

Don't trust your eyes.  Check the length of both strings and compare the ascii values, character by character. They might differ by some whitespace char's you can't see


<cfoutput>
len = #len(someValue)#<br>
<cfloop from="1" to="#len(someValue)#" index="x">
    <cfset c = mid(someValue, x, 1)>
     pos [#x#] = char #c# asii #asc(c)#<br>
</cfloop>
</cfoutput>

You are so right! I thought I would see extra spaces, etc. when I copied the contents to Word and chose to display hidden formatting symbols, but the differences didn't show there. By looping through each character and displaying the ascii value, I could see that the original encrypted value contained an extra space and a line feed that didn't display in Word. Some spot-checking showed that this is likely the case throughout.

I was ready to accept this as the solution, but I'm still left with lots of values encrypted under ColdFusion 7 which will not decrypt with ColdFusion 8 using the identical key. Any ideas there, given the standardized difference between the two encryptions? I tried simply trimming the original encrypted value before decrypting, hoping the extra space and line feed would be ignored, but that didn't work. Thanks for any help!

I _know_ I have heard of this issue before, but for the life of me I cannot remember the resolution.  Can you provide an example of the encrypt/decrypt that worked before but does not work now.  Obviously xxx out the confidential parts.

How much would you need to see in order for it to be useful? I'm understandably hesitant to post too much.

Well never post anything if you are not comfortable with it.  Plus I definitely do NOT need or want to see anything confidential posted here!  I was just looking for the basic shell code that does the encrypt/decrypt.  Once you plug in fake values like "myStringToEncrypt" and "myKey", the code is pretty much the same in any CF application .. and is no more than you see in livedocs


ie <cfset result = encrypt("myStringToEncrypt", "myKey", "AES", "Base64")>  
The actual settings:   AES, Base64, etc... are what is important to me.


I guess the reason I asked to see the code is because of the problem with whitespace and you mentioned something about a file? I was expecting a read from a db.  So it made me wonder if the code could possibly be trimming off extra white-space causing the problem.

But I am going to look around goole in the meantime and see if I cannot jog my memory about this issue.  

Gotcha ... for better or worse, I've used the default settings. I trimmed all strings before encrypting them. In my Google searching I came across references to "padding" which initially sounded promising, but I wouldn't think it would relate to my situation since I've used the default settings.

I'm reviewing my code again to see if I'm overlooking something ... since the only change was the upgrade to CF8 (no change to code or data), I can only guess that CF8 requires stricter adherence to something while CF7 was more forgiving.

> but I wouldn't think it would relate to my situation since I've used the default settings

Correct

Just for grins, did you try adding the encoding argument. If you are not using it already.
http://blog.cutterscrossing.com/index.cfm/2008/3/11/ColdFusion-8-Gotcha-The-Decrypt-Function

I SO thought that was going to work, but alas ... after adding the algorithm and encoding arguments, I no longer received an error message. However, the decrypted value was nothing, blank, empty.

It would seem that adding arguments is heading down the right path, but the arguments that worked for Cutter ...

Decrypt(stringToDecrypt,.key,'CFMX_COMPAT','Hex') />

... didn't work for me :-(

Try "UU" instead of "Hex".  I think that was the default for MX7

Sadly, replacing "Hex" with "UU" led to the original error.

"An error occurred while trying to encrypt or decrypt your input string: The input and output encodings are not same."

No better luck with base64, I'm afraid. I double-checked and we are running the latest CF8 update (8,0,1,195765). My original MX7 code only used the two required settings: string and key. I allowed algorithm to default to CFMX_COMPAT (at least that's what the documentation says is the default).

apparently, if your encrypted string contains characters like space, <, >, + or quotes, CF8 will not be able to decrypt it using CFMX_COMPAT algorythm...

i do not know if that's a bug in CF's implementation of java cryptography (and which CF version is buggy, if it is), or a flaw/differenced in JCE versions shipped with CF7 and CF8, but that's the fact.

i have found several questions regarding this, but no solutions... so the best thing you can do, i guess, is to install CFMX7 (if you do not have it installed), decrypt the strings, and then re-encrypt them using a different algorithm. you should then be able to decrypt them in CF8 using the new algorithm.

Azadi

some pointers:

http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:58296
http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:59834#325015

Azadi

Excellent find Azadi!

Thank you so much, both _agx_ and azadi, for putting in the time to help me troubleshoot this. I've applied Adobe's hot fix (how timely was that!) to my local CF server, and the application is now decrypting with ease. We'll be applying the hot fix to the production server later this evening. Thank you, thank you, thank you!!

cafoster, given the amazing timing you have, you should play the lottery today or something ;-)

Also, when you get time switch over to a better algorithm than "CFMX_COMPAT".  Even the documentation hints that it's a bit lame (read easily broken).   So it shouldn't be used for anything important ;-)