Re: [CFRG] compact representation and HPKE

   Hello,

On 2/15/21 8:50 AM, Richard Barnes wrote:
> 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?

   Yes, I think this is an acceptable way forward. I can get an I-D out RSN
in the expectation that RGLC finishes and we will soon have an HPKE RFC to
update.

   regards,

   Dan.

>
> --Richard
>
> On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan 
> <karthikeyan.bhargavan@inria.fr 
> <mailto: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 <mailto:CFRG@irtf.org>
>     https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius