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

[Christopher Wood <[e-mail]>]

On Tue, Nov 3, 2020, at 7:32 AM, Richard Barnes wrote:
> 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 <[e-mail]> 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.

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

Best,
Chris