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
