Re: [CFRG] compact representation and HPKE

Hi all,

Isn't the uncompressed form way more common?
I guess you can certainly use some compressed form for transport in that case...

B.

> On 6 Nov 2020, at 19:19, 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