Re: [CFRG] compact representation and HPKE

Hi folks,

I think Karthik is on the right track here.  While the compact
representation undoubtedly has its benefits, it seems like there is no
disagreement that it is not widely supported in either standards or crypto
libraries.  So there is a sizable community for whom a requirement to use
the compact format would render HPKE unusable.

Given that, I would propose we resolve this issue in the following way:
* In the current document, define KEMs for the NIST curves using the
uncompressed format.
* If there is a community that is *also* interested in supporting the
compact format, they can define new KEM code points for it.

Would folks be comfortable proceeding on that basis?

--Richard

On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan <
karthikeyan.bhargavan@inria.fr> wrote:

> I think the idea of having a compact representation of EC points for use
> in IoT-like scenarios is an attractive one, but the core ciphersuites of
> HPKE should only depend on standardized and widely-implemented point
> formats.
>
> In particular, HPKE is certainly not the right place to standardize a new
> EC point format, however sensible the change may seem.
> A protocol like EDHOC is laser-focused on small wire messages and is meant
> to be implemented by IoT-specific crypto libraries, and so it makes sense
> for that protocol to employ such optimizations.
> Perhaps the LAKE working group could drive a IETF/CFRG standard for x-only
> EC point representations that are more generally usable by other protocols?
>
> Having said all that, HPKE is extensible and we do anticipate extensions
> to HPKE in the near future, notably for adding PQ ciphersuites.
> I think the best way to proceed for compact HPKE would be, along the lines
> of Dan’s suggestion, to propose new KEM algorithm identifiers for compact
> encodings of the NIST curves, and to do this as part of a new CFRG draft as
> an extension to HPKE.
> I suspect that, beyond the point representation, we may find other parts
> of HPKE that would benefit from compaction for low-bandwidth scenarios.
>
> Best,
> Karthik
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>