Re: [CFRG] compact representation and HPKE

[Dan Harkins <[e-mail]>]

On 2/12/21 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.

   I see. So we go with the technically inferior approach, in order to 
"encourage people
to move to the CFRG curves."

   That's akin to "the beatings will continue until moral improves" and 
I don't think
that's what we're supposed to be doing here.

   We should go with the "technically superior approach", especially 
when that results
in a cleaner and more consistent API for HPKE.

   Dan.

> -Ekr
>
>
>
> On Fri, Nov 6, 2020 at 12:00 PM Dan Harkins <[e-mail] 
> <mailto:[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] <mailto:[e-mail]>
>     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