Re: [CFRG] compact representation and HPKE

As I understand it, the competing values here are:

(1) A technically superior approach (x-coordinate only)
(2) Consistency with existing uses of these curves (e.g., in TLS 1.3, which
uses x-coordinate-only form for CFRG curves but uncompressed form for NIST
curves).

Assuming I understand this correctly, I think I value consistency more,
especially in light of the fact that we are encouraging people to move to
CFRG curves anyway, which are already in the technically superior form.

-Ekr

On Fri, Nov 6, 2020 at 12:00 PM Dan Harkins <dharkins@lounge.org> wrote:

>
>    Hello,
>
>    When doing a DH-based KEM with the NIST curves, HPKE specifies that
> SerializePublicKey and DeserializePublicKey use the uncompressed format
> from SECG. This ends up using 2*Ndh+1 octets to represent the serial
> form of the public key.
>
>    Since compact output is being used in DH-based KEMs-- that is, the
> secret result of DH() is the x-coordinate of the resulting EC point--
> it would also be possible to use compact representation (per RFC 6090)
> and have SerializePublicKey merely do integer-to-octet string
> conversions of the x-coordinate. DeserializePublicKey would then
> do octet string-to-integer conversion for the x-coordinate and use the
> equation of the curve to choose the y-coordinate. The sign isn't
> important because we're doing compact output.
>
>    This would make the interface for the NIST curves and the Bernstein
> curves be uniform-- Serialize would produce an octet string of Ndh
> and Deserialize would consume an octet string of Ndh-- at the cost
> of some CPU inside DeserializePublicKey.
>
>    Please consider this suggestion.
>
>    regards,
>
>    Dan.
>
> --
> "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
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>