CFML and GCM/CCM cipher block mode transformations

75 views
Skip to first unread message

Denard Springle

unread,
Jun 27, 2016, 5:21:37 PM6/27/16
to Lucee
Hey Gang,

   WARNING: Crypto deep dive in progress...

   I've been playing a bit more with the encrypt() and decrypt() functionality within CFML recently and I've managed to get every single permutation of the available transformations in v7/v8 of java working with two exceptions... GCM (in v7/v8 java) and CCM (in v8 java) block modes. I've banged my head on this for a few days now - mostly as an exercise in self-abuse but also to see how well integrated the JCA/JCE is with CFML.

   I've done a ton of research and was able to get GCM working in pure Java no problem. The only difference I think I've found between what CFML is doing for the Initialization Vector (IV) and what I did is all in the spec that's used. For GCM it appears one must use GCMParameterSpec whereas everything else uses IvParameterSpec, and in both 4.5 and 5 source code (e.g. https://github.com/lucee/Lucee/blob/master/core/src/main/java/lucee/runtime/crypt/Cryptor.java) I see only IVParameterSpec is being used for all permutations.

   So, I guess my question is... would it be feasible/desirable to file an ER to check for a GCM transformation and instead call the GCMParameterSpec needed, and would this allow GCM to be used as a viable transformation with encrypt() and decrypt()? I ask merely because GCM seems to be the faster and more secure of the available options in Java (without license issues, anyway) and I would love to be able to use it. I noted in v8 they also introduced CCM (CBC + message auth) block mode, though I haven't gone down the rabbit hole on that one yet I expect the problem using it would be the same - I see a few mentions of CCMParameterSpec in google searches, but again, I haven't dove into that one.

   Anyone else played with the GCM or CCM block mode transformations and come up with a workable solution, or am I on the right track here that the GCMParameterSpec would need to be used under the hood, as it were, for the GCM transformations to work?

   I guess this question is mainly for the Lucee devs, but I'm open to hearing anyone else's experiences ;)

TEST CASE:

encrypt( 'test', generateSecretKey('AES'), 'AES/GCM/NoPadding', 'HEX', binaryDecode( left( hash( 'initvector'),16 ), 'hex' ) );


RESULT:

java.security.InvalidAlgorithmParameterException

Note that I get the same exception in Java when using IVParameterSpec instead of GCMParameterSpec with the GCM transformation

-- Denny
Message has been deleted

Andrew Penhorwood

unread,
Jun 28, 2016, 6:55:32 AM6/28/16
to Lucee
I think you should open a ticket and see where that goes.  Thanks for do all of the research on this.

Andrew Penhorwood

Denard Springle

unread,
Jun 28, 2016, 7:16:38 PM6/28/16
to Lucee
Added as issue LDEV-904 (https://luceeserver.atlassian.net/browse/LDEV-904)

Crossing fingers :)

-- Denny

Joseph Gooch

unread,
Jun 30, 2016, 4:18:13 PM6/30/16
to Lucee
Just as an initial take on this... seems like it should use AlgorithmParameters.getInstance(algorithm) instead of assuming the IV spec.

But my followup question to you is - GCM requires tLen in addition to the IV - so how do you supply that and what values are you playing with?

Joe


On Monday, June 27, 2016 at 5:21:37 PM UTC-4, Denard Springle wrote:

Denard Springle

unread,
Jun 30, 2016, 7:44:01 PM6/30/16
to Lucee
Hmm... I hadn't looked at using AlgorithmParameters.getInstance(algorithm) - but that would probably be a better solution - In my poorly written rusty Java code I checked for 'GCM' (or 'gcm') in the transformation and applied the right param based on that, but I'm going to go dork with getting the params from the algorithm now and see if that works better <g>. I think there still has to be some logic in there given GCM vs. CBC for example use a different byte count for the IV, but I'll see if I can figure that out ;)

For tag length I was using 16 * 8 (128) as a default in my Java testing. Pretty much every example I've come across thus far uses this as the default, so I did too, and I think that would probably be fine for a default within Lucee w/o having to alter encrypt() or decrypt() in any significant way to allow for passing the tag length.

-- Denny

Scott Smith

unread,
Aug 9, 2016, 7:04:13 PM8/9/16
to Lucee
--
Win a ticket to dev.objective from Lucee via Twitter, see http://bit.ly/1UbTMWjfor details, good luck and see you there...
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/fef368e0-14ff-47d1-a32d-492a2dd0a704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages