> On May 20, 2025, at 05:56, Sebastian Stenzel <sebastian.sten...@gmail.com> > wrote: > > 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)
Yes, this one is complex. > * Another reason is that it feels clunky to specify a key algorithm for the > PRK (does it need to be "Hmac-SHAnnn")? The modern algorithm for PRK is "Generic". See the new section for secret key algorithms at https://download.java.net/java/early_access/jdk25/docs/specs/security/standard-names.html#secretkey-algorithms. > * 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 You can specify "Generic" as the algorithm in the `deriveKey` call at the Extract-Only step to generate the "secret". I think some PKCS #11 library might not allow you to call `deriveData` here. I am not sure if I understand why the type of PRK could make multiple LabeledExpand more complicated. You can call `deriveKey` to generate the "key" and `deriveData` to generate the "base_nonce", but there is only one PRK. The code duplication is mostly at the labeling. > > Neither reason is a real blocker for me, though. Thanks for the understanding. > > 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. A new SecretKeyFactory for SunPKCS11 is introduced that is meant to translate a SecretKeySpec to an internal SecretKey. It's up to how the underlying PKCS #11 library supports it. Thanks, Weijun > > 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 >> >
