A128CBC+HS256 support in parity with Java's Nimbus JOSE + JWT

[patrickmcgannon]

Hi,

I have read in a lot of issues that jose-jwt strives to a level of support similar to that of the Java package nimbus-jose-jwt.

We are porting from Java to C# and I realized that the JWE token that we have always received from a partner uses A128CBC+HS256 which is not supported by jose-jwt, as it was deprecated in lieu of the similar A128CBC-HS256. **

Here is our Java code, for reference:

            EncryptedJWT encryptedJWT = EncryptedJWT.parse(jwt);
            JWEDecrypter decrypter = new RSADecrypter(privateKey);
            encryptedJWT.decrypt(decrypter);
            if (encryptedJWT.getState() != JWEObject.State.DECRYPTED) {
                throw new NotAuthorizedException("Invalid token. Decryption failed.");
            }
            SignedJWT signedJWT = SignedJWT.parse(encryptedJWT.getPayload().toString());
            JWSVerifier verifier = new RSASSAVerifier(publicKey);

I was wondering if there is either:

a. A way to workaround this limitation in jose-jwt since the algorithm isn't all that different from A128CBC-HS256, but obviously those differences are very low-level. b. A chance of supporting A128CBC+HS256 c. A recommendation for finding support elsewhere.

Error code for issue tracking: InvalidAlgorithmException: JWE algorithm is not supported: A128CBC+HS256.

and here is the Header for the encrypted token:

{
  "enc": "A128CBC+HS256",
  "alg": "RSA-OAEP",
  "cty": "JWT",
  "zip": "DEF",
  "x5t": "<redacted>"
}

Thanks!

** From a spec regarding their differences:

o  Replaced "A128CBC+HS256" and "A256CBC+HS512" with "A128CBC-HS256"
      and "A256CBC-HS512".  The new algorithms perform the same
      cryptographic computations as [I-D.mcgrew-aead-aes-cbc-hmac-sha2],
      but with the Initialization Vector and Authentication Tag values
      remaining separate from the Ciphertext value in the output
      representation.  Also deleted the header parameters "epu"
      (encryption PartyUInfo) and "epv" (encryption PartyVInfo), since
      they are no longer used.

[dvsekhvalnov]

Hi @patrickmcgannon , actually library supports little bit more than nimbus-jose-jwt :) Ok, honestly it's cross-tested against nimbus-jose-jwt on all algs, should be fully compatible.

A128CBC+HS256 - something long time ago deprecated or changed as you said, it's not standard alg identifier for quite some years. Library supports aliases for exactly that case, but you should enable them manually, please see here: https://github.com/dvsekhvalnov/jose-jwt#settings

[patrickmcgannon]

Thanks for pointing out that section. That's a great feature.

I don't know if A128CBC-HS256 is totally equivalent to A128CBC+HS256 if that is what you were saying. Also, see #43 for some historical context I found. I wasn't sure if this was similar to this.

Given this:

      Replaced "A128CBC+HS256" and "A256CBC+HS512" with "A128CBC-HS256"
      and "A256CBC-HS512".  The new algorithms perform the same
      cryptographic computations as [I-D.mcgrew-aead-aes-cbc-hmac-sha2],
      but with the Initialization Vector and Authentication Tag values
      remaining separate from the Ciphertext value in the output
      representation.  Also deleted the header parameters "epu"
      (encryption PartyUInfo) and "epv" (encryption PartyVInfo), since
      they are no longer used.

Do you think I should try to re-implement a part of the implementation using the settings you mentioned above?

[dvsekhvalnov]

Ah, indeed it was different enc algo with different KDF function. Not an alias. You can find details here: https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-encryption-08#appendix-A.4

But really, it was deprecated 10 years ago. You seriously want it?