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

Hi Chris,

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

On Tue, Nov 3, 2020 at 10:08 AM Christopher Wood <caw@heapingbits.net>
wrote:

> 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)
>

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.

> 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
>

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
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>