Re: [CFRG] compact representation and HPKE

[Christopher Wood <[e-mail]>]

On Fri, Feb 12, 2021, at 1:10 PM, Eric Rescorla wrote:
> 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.

To my knowledge, the compact representation (x-only) is (a) not widely supported, (b) not really standard (I don't think RFC 6090 or the related expired draft [1] rise to the level of a standard format), and (c) not FIPS compliant. Similarly, compressed representation seems not as widely supported as the uncompressed representation. 

So I concur with Ekr and Richard here: let's leave this as is. 

Best,
Chris

[1] https://tools.ietf.org/html/draft-jivsov-ecc-compact-05

> 
> -Ekr
> 
> 
> 
> On Fri, Nov 6, 2020 at 12:00 PM Dan Harkins <[e-mail]> 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
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>