shred / acme4j

Java client for ACME (Let's Encrypt)
https://acme4j.shredzone.org
Apache License 2.0
521 stars 96 forks source link

EAB HMAC keys with arbitrary lengths #141

Closed Radranic closed 1 year ago

Radranic commented 1 year ago

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)?

shred commented 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.

Radranic commented 1 year ago

Thank you!

Radranic commented 1 year ago

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!

shred commented 1 year ago

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.

shred commented 1 year ago

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!