Closed Radranic closed 1 year ago
This method is used for external account binding, and was meant for convenience. But to be honest, I never looked much deeper into external account binding after that implementation.
I will add a method to the AccountBuilder
for setting another HMAC algorithm. That should resolve the problem.
Thank you!
Just realized I don't know what kind of release schedule there is. Is there a rough estimate on when a release that would have this would be available?
Thanks again!
I am waiting for the release of BouncyCastle 1.77 to close a potential vulnerability in acme4j-smime (see #142). However there are also other changes that are ready for release, so I think I will do a release by this week, and another one when BouncyCastle is available.
I just released acme4j 3.1.0 with the fix. If there is still a problem with the HMAC keys, feel free to reopen this issue. Thank you!
The function here:
https://github.com/shred/acme4j/blob/dd7c87375032e25c08cf22fa6b98c193e1fbbe5b/acme4j-client/src/main/java/org/shredzone/acme4j/toolbox/JoseUtils.java#L240
Assumes that any HMAC key will be of an exact key length matching the SHA strength.
From RFC 7518 JSON Web Algorithms, section 3.2 (https://www.rfc-editor.org/rfc/rfc7518.html#section-3.2) is says: A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm.
The "or larger" isn't supported by the logic currently used to select which algorithm to pick.
Would it be possible to switch the logic to use the highest possible algorithm strength for any given key length (minimum 256)?