CFML and GCM/CCM cipher block mode transformations

dev google-group-archive
1

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.
Lucee/Cryptor.java at master · lucee/Lucee · GitHub)
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 :wink:

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

2

Added as issue LDEV-904 ([LDEV-904] - Lucee)

Crossing fingers :slight_smile:

– Denny

3

I think you should open a ticket and see where that goes. Thanks for do
all of the research on this.

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

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.
Lucee/core/src/main/java/lucee/runtime/crypt/Cryptor.java at master · lucee/Lucee · GitHub)
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 :wink:

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

4

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?

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

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.
Lucee/core/src/main/java/lucee/runtime/crypt/Cryptor.java at master · lucee/Lucee · GitHub)
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 :wink:

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

5

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 . 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 :wink:

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.

– DennyOn Thursday, June 30, 2016 at 4:18:13 PM UTC-4, Joseph Gooch wrote:

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:

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.
Lucee/core/src/main/java/lucee/runtime/crypt/Cryptor.java at master · lucee/Lucee · GitHub)
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 :wink:

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

6

UihvOn Jun 30, 2016, 6:44 PM -0500, Denard Springle <@Denard_Springle>, wrote:> 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 . 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 :wink:

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

On Thursday, June 30, 2016 at 4:18:13 PM UTC-4, Joseph Gooch wrote:

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:

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. Lucee/core/src/main/java/lucee/runtime/crypt/Cryptor.java at master · lucee/Lucee · GitHub) 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 :wink:

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

–
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+unsubscribe@googlegroups.com (mailto:lucee+unsubscribe@googlegroups.com).
To post to this group, send email to lucee@googlegroups.com (mailto:lucee@googlegroups.com).
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/fef368e0-14ff-47d1-a32d-492a2dd0a704%40googlegroups.com (https://groups.google.com/d/msgid/lucee/fef368e0-14ff-47d1-a32d-492a2dd0a704%40googlegroups.com?utm_medium=email&utm_source=footer).
For more options, visit https://groups.google.com/d/optout.