Re: [CFRG] RFC9180/HPKE erratum on recommended sizes

[Ilari Liusvaara <[e-mail]>]

On Thu, Nov 17, 2022 at 10:04:33AM -0500, David Benjamin wrote:
> Our implementation doesn't impose any particular limits on info. But this
> maybe points to a larger issue here. The resolution of
> https://github.com/cfrg/draft-irtf-cfrg-hpke/issues/226 to recommend using
> info like an AEAD's aad parameter, which typically does not have tight
> limits. And, even independent of that advice, non-single-shot uses (like
> ECH) may well have non-trivial per-context additional authenticated data.
> For ECH in particular, should we ever stick PQ KEMs into ECH, the info
> field will become a lot larger.
> https://www.rfc-editor.org/rfc/rfc9180.html#section-8.1

For the implementation I have written, the only limit on info is
fitting into the memory space.


> Looks like the size issue comes from info being used as the IKM to
> LabeledExtract, which constructs a labeled_ikm by prepending a prefix.
> This means that, if your HKDF API requires contiguous IKMs, you need
> to make a copy of the info string.
> https://www.rfc-editor.org/rfc/rfc9180.html#section-5.1-9
> https://www.rfc-editor.org/rfc/rfc9180.html#section-4-9
> 
> I would not expect most HKDF-Extract APIs to support discontiguous
> IKMs, as that's kinda weird for keying material. Then again, if we
> break the abstraction, it's just the body of an HMAC, which typically
> can be streamed, much less discontiguous. So we do't *actually* need
> to make a copy here. But breaking the abstraction here is not ideal
> because HPKE aims to abstract over KDFs. So if we want to rely on
> that, we might need to make a note to tweak the definition for future
> KDFs so they don't need to rely on the HMAC internals.

The implementation I have written has internal abstraction for KDF that
can take suitable discontiguous IKM. It does not need to copy the IKM.
Currently the only implemented KDF is HKDF<H>.


And on new KDFs, one would probably want a KDF based on SHA-3, as most
PQC stuff (especially Kyber) internally uses SHA-3 (I first took a look
at NIST SP 800-56C rev 2 if it defines something suitable, but alas, it
does not).


One proposal:


Extract(ikm, salt):

- If no salt specified, default to empty octet string.
- Run KMAC256 with:
  + K = <salt>  
  + X = <ikm>
  + L = 512
  + S = "KDF-extract"
- Return the 64 octet result from KMAC256.


Expand(prk, info, L):

- Run KMAC256 with:
  + K = <prk>
  + X = <info>
  + L = 8*<L>
  + S = "KDF-expand"
- Return the octet string result from KMAC256.


Both steps behave very similarly to the corresponding steps of HKDF
The multiply by 8 in expand is due to expand taking length in octets,
but KMAC wanting length in bits.




-Ilari