@ddspringle Thank you for picking up FW/1, excited to see where it goes from here 🙂 We have implemented a version of your framework-one-secure-auth in a legacy ACF app which we are now migrating over to FW/1. Thank you for making that available! Everything works great on JDK11, now we've upgraded to CF2023, which as you know is supporting JDK17. Reading the keyring file into memory is failing with unsupported algorithm errors, as well as other locations dataDec is called. Was wondering if you were aware and maybe no of a fix? Any tips would be very much appreciated. Thanks!! Rich

Hmm... I haven't actually tried that sample code in 2023 yet. I suppose it is feasible they removed an algorithm, or perhaps renamed it in the latest Java release. I had a similar issue posted recently for Lucee that I couldn't reproduce, but now I'm wondering if it wasn't actually an underlying Java change in the JCE. A quick look suggests the JCE in 17 still supports both AES and BLOWFISH algorithms, which are the only two I think I used in my key generation code. Let me double-check that, one sec...

Hey, good morning. Thanks for taking a look. I am going to be digging in a bit more over the next few days and will let you know what I've found. I don't believe I deviated too far from your release, but it has been 2 years since it was implemented. Thanks again, I will get back to asap.

I don't believe you need to rekey. I'd hold off on that. The PBKDF warning only applies if you upgraded from a previous version of that particular fw1 example app to a newer version of it where that breaking change had been made. You can compare your Application.cfc to the one in the repository (https://github.com/ddspringle/framework-one-secure-auth/blob/master/Application.cfc) and should readily be able to see if they match in terms of using PBKDF or not - the older version would not have any PBKDF code in it, basically. And doing so I don't think would produce what you're seeing reading the keyring file - it should error out at dataDec() if it has a problem decrypting the data. It is not, however, and just tries to parse encrypted keyring data as JSON. 🤔 Might this be somehow accidentally double-encrypted? idk... throwing out ideas here... it's the only way I can see from looking at the code that you'd still have an encrypted value after successfully decrypting it once. If it was an algo or key error, dataDec() would throw an error to that effect. Ok, this is a shot in the dark here, but try this: 1. Backup your existing keyring file 2. Add these lines of code above line 950 in SecurityService.cfc:

writeOutput( dataDec( charsetEncode( fileReadBinary( variables.keyRingPath ), 'utf-8' ), 'master' ) );

3. launch the application and get the value returned from this new line of code. 4. Copy and paste it into your existing (actively used, not backup) keyring file - you can open that .bin file in notepad or whatever and paste it in. 5. Launch it again and see if you get JSON instead of an encrypted value. If you do, problem solved - replace your backup keyring with the one that now works and remove the line of code from SecurityService.cfc added per above and all should be right with the world again. If not - check that it is not the same encrypted value as this one. If it is, then I'll have to scratch my head more. If it isn't then copy that value in and so on and so forth until you either get a decryption error or reach JSON. The decrypted JSON is what you're after. ------- Beyond that I'll have to dig deeper. Perhaps we can get in a screen share on Monday (or perhaps over the weekend) and try and walk (crawl, trip, stumble, fall) through my code in your app and see if we can't narrow it down further.

Hi, @ddspringle thanks again! Not sure you caught it in my original post but, this implementation is not in a FW/1 app, it is in our legacy app we are slowly migrating to FW/1. I really wanted to take advantage of the features before we were ready to go FW/1. With that said, it is still very close to what you released. The main difference is we are instantiating the securityService in application.cfc and storing it in the app scope to simulate a FW/1 singleton service. I can switch CF2023 to use JDK11 and it is fine, switch to JDK17 and not so good. We are actually live in production with CF2023 running JDk11 and really want to get to the right version lol. I'm sure it wasn't double encrypted. I would love to take you up on a screen share. I'm just about done for today, and to tomorrow Sunday I will be away. Monday is quite possible. Let me know. Thanks, Rich

@Rich Symons Sorry for the delay. I can confirm that JDK17 does cause issues with encryption/decryption, and it appears to be related with the CTR mode of encryption. It would appear that JDK17 started enforcing the use of an Initialization Vector (IV) with the CTR mode - which my old code does not do for the master key (but does do for keys in the keyring). In local testing, changing the master key algorithm from

BLOWFISH/CTR/PKCS5Padding

to

BLOWFISH/CBC/PKCS5Padding

solved the problem. I could have also added an IV to the master key encryption/decryption but this was easier. Blowfish isn't exactly the most secure algorithm to use anymore anyway so I will most likely eliminate that algo in that repository, but that doesn't help you a whole lot, so I'll try and figure out the least painful way to address this issue for you. It may just be a matter of decrypting the existing keyring with JDK11 and then re-encrypting the keyring using either CBC mode or adding an IV with the CTR mode in the master encryption/decryption modes in

dataEnc()

and

dataDec()

in

SecurityService.cfc

respectively. To do this, I would write code that simply copies the existing encrypt and decrypt for the master key type from SecurityService.cfc, then code to re-encrypt using CBC mode or adding an IV, then switching SecurityService.cfc's algo for the one you used to re-encrypt. Then everything should work on JDK17.

Awesome @ddspringle! Thanks for all the effort. I should be able to take a stab at this later today or tomorrow and will let you know how I made out. Thanks Again! Rich

Sweet! It was my pleasure to help and glad we found the root cause and a solution. And for a minute there I wasn't sure I was going to be able to figure it out lol