Re: [CFRG] [Cfrg] I-D Action: draft-irtf-cfrg-hpke-06.txt

[Christopher Wood <[e-mail]>]

On Wed, Oct 28, 2020, at 4:21 PM, Christopher Wood wrote:
> On Mon, Oct 26, 2020, at 10:04 AM, Christopher Patton wrote:
> > Hi all,
> > 
> > I agree that we shouldn't discourage adoption of alternatives to HKDF. 
> > However, I don't think the spec does so: it merely requires adherence 
> > to the Extract-then-Expand API. There should be ways to securely "wrap" 
> > alternatives into Extract-then-Expand API providers, perhaps at the 
> > cost of CPU cycles. (E.g., how Noise uses Blake2b as pointed out above.)
> 
> +1.
> 
> The two-step Extract-then-Expand split does not rule out other KDFs and 
> allows best use of HKDF out of the box. Consequently, I don't think the 
> HPKE specification should change at this point.

To be more concrete, if desired, one could wrap HKDF as follows:

  Extract(salt, ikm): HKDF(secret=ikm, salt=salt, info="", length=Nh)
  Expand(prk, info, L): HKDF(secret=prk, salt="", info=info, length=L)

Similarly, I think one could wrap BLAKE3 as follows:

  Extract(salt, ikm): derive_key(context=salt, key_material=ikm), and output Nh bytes
  Expand(prk, info, L): derive_key(context=info, key_material=prk), and output L bytes

Best,
Chris