Re: [CFRG] compact representation and HPKE

[John Mattsson <[e-mail]>]

+1

Sending the keys uncompressed makes HPKE unsuitable for constrained IoT.

-----Original Message-----
From: CFRG <[e-mail]> on behalf of Dan Harkins <[e-mail]>
Date: Friday, 6 November 2020 at 21:00
To: CFRG <[e-mail]>
Subject: [CFRG] compact representation and HPKE

   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://protect2.fireeye.com/v1/url?k=513cd874-0ea7e231-513c98ef-867b36d1634c-ce26b08a2499b9a3&q=1&e=4f2b4ce0-8d52-4a80-b41e-0f7537355d35&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg