Hi, thank you for your fast replies!
* One benefit of using byte[] is that I can nil the PRK after I’m done (while secretKey.destroy() isn’t well supported, see my other post from yesterday on this mailing list) * Another reason is that it feels clunky to specify a key algorithm for the PRK (does it need to be "Hmac-SHAnnn")? * In places where I want to expand both keys and bytes from a single PRK (as with "secret" here [1]), I need quite a bit of code duplication for the `labeledExpand` operations with different return types Neither reason is a real blocker for me, though. That said, please consider that the HKDF RFC specifically mentions the possibility to directly expand a suitable uniformly random IKM, skipping the extract phase [2]. Arguing that some providers won’t accept this is an incomplete implementation of a standard. Best regards, Sebastian [1]: https://www.rfc-editor.org/rfc/rfc9180#section-5.1-10 [2]: https://datatracker.ietf.org/doc/html/rfc5869#section-3.3 > On 19. May 2025, at 20:49, Wei-Jun Wang <weijun.w...@oracle.com> wrote: > > Hi Sebastian, > > Thanks for your interest on the KDF APIs. > > As the name suggests, the PRK is a key, and we've represented it as a > SecretKey. It's always complete, of fixed length, and provided in a single > step. This is quite different from the IKM, which may come in various forms, > or even a combination of them, such as labeled IKM, which you're likely > familiar with from your work on HPKE. To support those cases, we offer > multiple addIKM methods. By contrast, providing the PRK as a byte[] seems to > offer limited practical benefit. As Daniel pointed out, it might not even be > feasible in some contexts. > > Best wishes, > Weijun > > >> On May 19, 2025, at 10:06, Daniel Jeliński <djelins...@gmail.com> wrote: >> >> Hi Sebastian, >> The PRK argument always comes from a LabeledExtract output in the RFC >> you cite. You can use extract + thenExpand, or generate key material >> for expand with deriveKey. Is there any case where you need the prk as >> a byte array? >> >> Note that certain providers (PKCS11) may or may not support >> externally-supplied byte arrays as PRK, and should always be used with >> a SecretKey. >> Regards, >> Daniel >> >> pon., 19 maj 2025 o 12:22 Sebastian Stenzel >> <sebastian.sten...@gmail.com> napisał(a): >>> >>> Hi, >>> >>> I’m using the HKDF extract and expand steps separately for this step [1] in >>> HPKE. >>> >>> In this case I need to pass a byte[] prk to expandOnly(…), however the API >>> only accepts a SecretKey, forcing me to wrap the bytes just for them to be >>> unwrapped by the expand operation again. Probably this has already been >>> discussed, so please feel free to point me to any existing rationale. >>> >>> Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` >>> function? >>> >>> Cheers, >>> Sebastian >>> >>> [1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10 >
