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

From: "Christopher Wood" <[email-masked]>
Date: Tue, 03 Nov 2020 07:06:58 -0800

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 3 Nov 2020 10:32:44 -0500

Hi Chris,

I agree with your analysis here, but a couple of refinements/extensions
inline below...

>   Expand(prk, info, L): HKDF(secret=prk, salt="", info=info, length=L)

One could do that, but it would be kind of silly, when the whole point of
the extract/expand API is that it maps well to two-step KDFs.  Rather, I
think the point here is that in addition to HKDF, you could fit other
two-step KDFs into this API, such as the one defined for KMAC in NIST SP
800-56C.

>   Expand(prk, info, L): derive_key(context=info, key_material=prk), and

Since I have 800-56C open, I would note that the two-step construction
there uses a MAC for extract and a KDF for expand, so you could also do an
integration of that form:

Extract(salt, ikm) = BLAKE3.MAC(salt, ikm)
Expand(prk, info, L) = BLAKE3.KDF(prk, info, L)

In any case, it seems clear that if you have a two-step KDF, you can
probably map it into the extract/expand API, and if you have a one-step
KDF, you can just invoke it twice if there's not a more elegant option.

--Richard

> Best,
> Chris
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 03 Nov 2020 09:56:49 -0800

On Tue, Nov 3, 2020, at 7:32 AM, Richard Barnes wrote:
> On Tue, Nov 3, 2020 at 10:08 AM Christopher Wood <[email-masked]> wrote:
> One could do that, but it would be kind of silly, when the whole point 
> of the extract/expand API is that it maps well to two-step KDFs.  
> Rather, I think the point here is that in addition to HKDF, you could 
> fit other two-step KDFs into this API, such as the one defined for KMAC 
> in NIST SP 800-56C.
>  
> there uses a MAC for extract and a KDF for expand, so you could also do 
> an integration of that form:
> 

Yep! I oversimplified for effect, but your explanation is much more clear. 

Best,
Chris