> On May 20, 2025, at 05:56, Sebastian Stenzel
> 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,
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
(d
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 combin
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
