HmacSecretKey.importJsonWebKey ignores length

[harrshita123]

Description

HmacSecretKey.importJsonWebKey accepts a length parameter, but the public wrapper does not forward it to the backend. As a result, importing the same HMAC key material as raw bytes and as JWK can produce different key bytes and different signatures whenever length trims bits from the final byte.

This breaks the package's cross-format parity: HmacSecretKey.importRawKey(..., length: n) honors the requested HMAC key length, while HmacSecretKey.importJsonWebKey(..., length: n) silently uses the full JWK k value.

Expected behavior

JWK import should honor length the same way raw import does. In the example above, both imports should export [255, 128], and signatures produced by the two keys should match.

Actual behavior

The length argument is dropped in HmacSecretKey.importJsonWebKey, so the JWK-backed key keeps the untrimmed final byte and signs/verifies with different key material.

Notes

A fix should also validate JWK import length consistently with raw imports so the native backend does not silently accept invalid lengths.

[jonasfj]

I think we should review the other importJsonWebKey methods we have in the package.

The question is:

• Should length parameter be there?
• If length parameter must be there, is it to be understood as:
  • (A) We verify that the size of the imported key matches length.
  • (B) We reduce / limit the size of the imported key to match length.

(B) would be a mutation, I would think that wrong.

---

I could be wrong here, but if you look at the other importJsonWebKey methods on other primitives, they generally do take Hash or EllipticCurve, but they don't use it to convert/force the jwk into having said hash or curve, instead they use it to verify that what is imported actually matches the expected hash or curve.

I think the reason we did it this way is that JWKs can be a bit dangerous, if you blindly import a JWK without verifying that it has the expected algorithm, hash, curve, parameters, then you are potentially letting an adversary conduct a downgrade attack. Potentially, depends on how you're using it.

I think package:webcrypto takes the opinion that when you import a JWK, you must also tell us what kind of JWK you are expecting (hash, curve), and if JWK you are importing don't match then we reject it.

Users who want to support importing an arbitrary JWK with any hash or curve, can just read the JWK upfront find the hash/curve and pass it into importJsonWebKey. So this opinion doesn't limit what people can do, it just makes it a bit more difficult to do this without being explicit about it.

I think the reason we take this opinion is that: generally when you're importing a JWK, probably know what algorithm, hash/curve you are importing. Thus, you should validate this! By structuring the API this way, we force users to validate algorithm, hash/curve.

Please review the other importJsonWebKey methods, but I think this is what we do, and I think this is a deliberate opinion we've taken. I'm open to debating the merits of such opinion in a separate issue. Because, yes technically, when we import a JWK, we don't need users to pass in hash or curve parameters.

---

If the opinion above is what we have, then the question becomes:

• Should length parameter be there?
• Should it be required or optional?
• Can we actually verify it? I suspect not, because really length just means make the remaining bits zero. ANd we cannot tell whether the remaning bits on jwk.k are zero by accident or zero because the key has the given length.

Granted we can validate that jwk.k has expected length and the remaining bits are zero. Which indicates that probably it has the expected length.

I could be convinced length should be removed? or that we should attempt to validate it.

[harrshita123]

I think we should review the other importJsonWebKey methods we have in the package.

The question is:

• Should length parameter be there?

• If length parameter must be there, is it to be understood as:

  • (A) We verify that the size of the imported key matches length.
  • (B) We reduce / limit the size of the imported key to match length.

(B) would be a mutation, I would think that wrong.

I could be wrong here, but if you look at the other importJsonWebKey methods on other primitives, they generally do take Hash or EllipticCurve, but they don't use it to convert/force the jwk into having said hash or curve, instead they use it to verify that what is imported actually matches the expected hash or curve.

I think the reason we did it this way is that JWKs can be a bit dangerous, if you blindly import a JWK without verifying that it has the expected algorithm, hash, curve, parameters, then you are potentially letting an adversary conduct a downgrade attack. Potentially, depends on how you're using it.

I think package:webcrypto takes the opinion that when you import a JWK, you must also tell us what kind of JWK you are expecting (hash, curve), and if JWK you are importing don't match then we reject it.

Users who want to support importing an arbitrary JWK with any hash or curve, can just read the JWK upfront find the hash/curve and pass it into importJsonWebKey. So this opinion doesn't limit what people can do, it just makes it a bit more difficult to do this without being explicit about it.

I think the reason we take this opinion is that: generally when you're importing a JWK, probably know what algorithm, hash/curve you are importing. Thus, you should validate this! By structuring the API this way, we force users to validate algorithm, hash/curve.

Please review the other importJsonWebKey methods, but I think this is what we do, and I think this is a deliberate opinion we've taken. I'm open to debating the merits of such opinion in a separate issue. Because, yes technically, when we import a JWK, we don't need users to pass in hash or curve parameters.

If the opinion above is what we have, then the question becomes:

• Should length parameter be there?
• Should it be required or optional?
• Can we actually verify it? I suspect not, because really length just means make the remaining bits zero. ANd we cannot tell whether the remaning bits on jwk.k are zero by accident or zero because the key has the given length.

Granted we can validate that jwk.k has expected length and the remaining bits are zero. Which indicates that probably it has the expected length.

I could be convinced length should be removed? or that we should attempt to validate it.

Thanks for the detailed explanation.

I agree that for importJsonWebKey, the extra parameters should be treated as expectations/constraints for the imported JWK, not as instructions to transform the key material. That is consistent with how the other JWK import APIs use hash / curve: they validate that the JWK matches what the caller expected, rather than coercing the JWK into that shape.

So my current PR is too broad in one important way: it makes JWK import behave like raw import by allowing the decoded key bytes to be reduced/zeroed to match length. Based on your comment, JWK import should not mutate the key. It should either accept the JWK as-is or reject it.

The behavior that now seems correct to me is:

• If length is not provided, keep the existing behavior.
• If length is provided, treat it as the expected HMAC key length.
• Validate that jwk.k has the expected encoded key size.
• If length is not byte-aligned, validate that the unused trailing bits are already zero.
• If those checks fail, reject the JWK, probably as a FormatException, because the JWK does not match the expected format/parameters.

I can update the PR in that direction: remove mutation semantics, change the regression test to assert validation-only behavior, and move the validation into the implementation if that better matches the package structure.