
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi,<div><br></div><div>thank you for your fast replies!</div><div><br></div><div>* 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)</div><div>* Another reason is that it feels clunky to specify a key algorithm for the PRK (does it need to be "Hmac-SHAnnn")?</div><div>* 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</div><div><br></div><div>Neither reason is a real blocker for me, though.</div><div><br></div><div>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.</div><div><br></div><div>Best regards,</div><div>Sebastian</div><div><br></div><div>[1]: <a href="https://www.rfc-editor.org/rfc/rfc9180#section-5.1-10">https://www.rfc-editor.org/rfc/rfc9180#section-5.1-10</a></div><div>[2]: <a href="https://datatracker.ietf.org/doc/html/rfc5869#section-3.3">https://datatracker.ietf.org/doc/html/rfc5869#section-3.3</a></div><div><br></div><div><div><br><blockquote type="cite"><div>On 19. May 2025, at 20:49, Wei-Jun Wang <weijun.wang@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Hi Sebastian,<br><br>Thanks for your interest on the KDF APIs.<br><br>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.<br><br>Best wishes,<br>Weijun<br><br><br><blockquote type="cite">On May 19, 2025, at 10:06, Daniel Jeliński <djelinski1@gmail.com> wrote:<br><br>Hi Sebastian,<br>The PRK argument always comes from a LabeledExtract output in the RFC<br>you cite. You can use extract + thenExpand, or generate key material<br>for expand with deriveKey. Is there any case where you need the prk as<br>a byte array?<br><br>Note that certain providers (PKCS11) may or may not support<br>externally-supplied byte arrays as PRK, and should always be used with<br>a SecretKey.<br>Regards,<br>Daniel<br><br>pon., 19 maj 2025 o 12:22 Sebastian Stenzel<br><sebastian.stenzel@gmail.com> napisał(a):<br><blockquote type="cite"><br>Hi,<br><br>I’m using the HKDF extract and expand steps separately for this step [1] in HPKE.<br><br>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.<br><br>Otherwise, is it too late to ask you to add a `expandOnly(byte[] prk)` function?<br><br>Cheers,<br>Sebastian<br><br>[1] https://www.rfc-editor.org/rfc/rfc9180#section-4-10<br></blockquote></blockquote><br></div></div></blockquote></div><br></div></body></html>