On 3/13/24 08:52, Wei-Jun Wang wrote:
On Mar 12, 2024, at 6:34 PM, Martin Balao wrote:
As I understand it, it's not that state is not maintained but that we are
keeping it on the parameters side. For example, a extraction phase call will
generate a PRK that will be kept in the parameters si
> On Mar 12, 2024, at 6:34 PM, Martin Balao wrote:
>
> As I understand it, it's not that state is not maintained but that we are
> keeping it on the parameters side. For example, a extraction phase call will
> generate a PRK that will be kept in the parameters side for the following
> expansi
Hi Kevin,
Thanks for your quick response.
On 3/12/24 17:52, Kevin Driver wrote:
To be brief, we will be removing the length parameter from the deriveKey
arguments list. There was some thought that there may be a use-case
where the caller would not want to use all the generated entropy, but at
Hi Martin.
To be brief, we will be removing the length parameter from the deriveKey
arguments list. There was some thought that there may be a use-case where the
caller would not want to use all the generated entropy, but at this time, we
have no valid use-case for this in the current API desig
Hi Kevin,
When looking at the proposed API, I noticed that the length of a derived
key or data can be potentially passed both as part of a KDFParameterSpec
and as a KDF::deriveKey or KDF::deriveData parameter. This is the case
for HKDF (HKDFParameterSpec) apparently. Having a length value on t
Hi All,
As discussed a few months ago [1], we are working on providing a new API for
KDF (Key Derivation Functions). There will be a KDF class for users, a KDFSpi
class for security providers, and several other parameter classes. We plan to
add support for HKDF (RFC-5869).
For more details, se
