JWE -> How to use - alg dir with enc A256CBC-HS512

[API-Evangelist]

How to use JWE with alg dir and enc A256CBC-HS512 in latest 4.50 version?

Please point be a good documentation or section which will help with all supported algo's information..

https://tools.ietf.org/html/rfc7518#section-4.1

https://tools.ietf.org/html/rfc7518#section-5.1

Using like below it is not impressed and please guide if i am missing anything..

The "A256CBC-HS512" encryption method or key size is not supported by the JWE encrypter: Supported methods: [A128GCM]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GenerateJWT name="GJ-Token">
    <Algorithms>
        <Key>dir</Key>
        <Content>A256CBC-HS512</Content>
        <!--<Content>A128GCM</Content>-->
    </Algorithms>
    <DirectKey>
        <Value encoding="base64" ref="private.Key"/>
    </DirectKey>
    <Subject ref="private.subject"/>
    <Issuer ref="private.issuer"/>
    <Audience ref="private.audience"/>
    <ExpiresIn>10m</ExpiresIn>
    <OutputVariable>output-jwt</OutputVariable>
</GenerateJWT>

[dchiesa1]

You are using OPDK, correct? I think you need to install the Java Unlimited Strength Crypto extension policy file in your JDK in order to get strong security. Have you done that?

Your policy configuration looks fine.

This message

The "A256CBC-HS512" encryption method or key size is not supported by the JWE encrypter:

...I think stems from the inability of the JVM to load the appropriate crypto.

[API-Evangelist]

Correct. It's OPDK..Tried as suggested but didn't see any difference.

Any thing else missing? Will open a case but in general outside JCE anything we need to do?

https://bitbucket.org/b_c/jose4j/wiki/Home

==

* Requires the JCE's Unlimited Strength Jurisdiction Policy Files be installed for the JRE (download for Java 7 and Java 8 and note that later versions have the unlimited cryptographic policy enabled by default).
† Requires Java 11, Java 8 Java 8u251, or the Bouncy Castle JCA provider (or another provider which supports RSASSA-PSS)
‡ Requires Java 8 or the Bouncy Castle v1.50+ JCA provider (or another provider which supports AEAD ciphers though the JCA interface including recognizing GCMParameterSpec)
¶ Requires Java 8 or the Bouncy Castle JCA provider (or another provider which supports RSA/ECB/OAEPWithSHA-256AndMGF1Padding and an OAEPParameterSpec that indicates SHA-256 for MGF1)

==

The "A256CBC-HS512" encryption method or key size is not supported by the JWE encrypter: Supported methods: [A128GCM]

[dchiesa1]

I can't see anything else missing. We run tests with A256CBC-HS512.

I just conducted a couple specific tests.

1. Just checking, on Java8 u151 and later, unlimited strength crypto is on by default.

   If I explicitly "turn off" unlimited strength crypto, then I get

   fault code = steps.jwt.EncryptionFailed 
   fault message = Failed to encrypt: policy(enc-025)
   	

   and the "error" variable gets set to "Illegal key size"

2. If I supply a directkey that decodes to something less than 512 bits, then I get an error of

   fault code = steps.jwt.InsufficientKeyLength
   fault message = The symmetric key is of the wrong length: policy(enc-025)
   	

That's not what you are seeing.

Something else is going wrong .

[dchiesa1]

Can you try encoding your direct key as hex, rather than base64?

[luisfelipecosta · Accepted solution]

@Vinay, we had this problem too. The solution was to adapt the key length. Just for testing, try to generate a base64 key with 64 bytes length.

You can do it here. (You need to set the length)

Hope it helps.

[API-Evangelist]

Thankyou. It worked.

[dchiesa1]

Yes, for direct keys, you need to specify an encoded key of the exact length required. For A256CBC-HS512, that means 64 bytes.

[ronnieroyston]

Just FYI: authenticated AES encryption in CBC mode is discouraged as it is very easy to make a mistake. AES in GCM mode includes authenticated encryption by default and is recommended.

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt#supported_algorithms

While it's possible to add authentication to CTR and CBC modes, they do not provide it by default and when implementing it manually one can easily make minor, but serious mistakes. GCM does provide built-in authentication, and for this reason it's often recommended over the other two AES modes.

[dchiesa1]

I think your reply is misleading and not helpful here.

...when implementing it manually one can easily make minor, but serious mistakes.

The statements are true enough on their own, but your comment is inapplicable to this discussion, because Apigee users won't be implementing AES manually. In this 2-year old thread, we had been discussing the use of the JWE policy in Apigee, and that implements RFC7516, which rolls authentication on top all of the various JWA encryption Algorithms, via the authentication tag in the JWE. All of this happens automatically in the policy and there's no need for people who use the Apigee policy to be concerned about "manual implementation". 

It seems like you've just cut/pasted text from the Mozilla website into a random2-year old thread that mentions AES.

But that documentation page specifically refers to the webcrypto API, the browser API that offers low-level crypto capabilities for apps that run in the browser. Concerns about "Manual implementation" would apply to the use of the webcrypto API.  But not to the Apigee policy.

Maybe your reply was posted by a bot? We're seeing more of that these days, here on this community.

[ronnieroyston]

I misunderstood the subject of the thread. Notice how inconspicuous the term Apigee is and how the title appears as JWE alg:dir w/ AES CBC. I came across this page while searching JWE implementations.

I can say that your comments are effectively public humiliation, which is not acceptable especially as you are tagged as staff. BTW the WebCrypto API is not exclusive to apps that run in the browser (e.g. see Node.js crypto.subtle).  Lastly, RFC 7516 does not "roll auth on top of JWA". 7516 is titled "JSON Web Encryption (JWE)" and includes support for unauthenticated encryption.

[dchiesa1]

your comments are effectively public humiliation, which is not acceptable

I never intend to humiliate anyone, only to help clarify issues for patrons of this community. For future readers, your prior comment will not be helpful, and will not clarify things. It relates only to scenarios that are not Apigee, and this space is for Apigee. By saying "I misunderstood the subject of the thread. Notice how inconspicuous the term Apigee is",  I think you're ducking your own responsibility here. If you want to contribute materially, understand the context. Flybys don't work that well. 

I considered just removing your comment, but rather than do that, assuming your comment was offered in good faith, I pointed out that your comment is irrelevant. I'm sorry if you don't like that; it's not personal, it's not about you. I stand by that assessment. 

Maybe I will just go back and remove your comment, because now we are just having a distracting meta-conversation, which is.. also not helpful.