Re: [CFRG] compact representation and HPKE

[Dan Harkins <[e-mail]>]

   Hi Chris,

On 2/12/21 1:40 PM, Christopher Wood wrote:
> 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,

   What kind of support is needed? It can be used, with any setting for 
the sign
bit, to reconstruct a point on the curve using any crypto library that 
supports
compressed points, and I think they all do that today. The x-only Montgomery
Ladder is probably not widely supported but maybe this will be the 
compelling
reason to implement it. And from what Loup Vaillant-David says, it would be
a good thing if they did.

> (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

   Well SECG was basically Certicom and they kind of dictated what the 
"standard"
for ECC became. SECG was never an SDO although one can, I guess, call widely
supported specifications standards.

   But I don't think there needs to be historically documented use for 
HPKE to
adopt this. In any event, as John Mattsson notes, EDHOC will be using x-only
for all curves so there is a band wagon we can jump on.

> (c) not FIPS compliant.

   I really don't understand this. FIPS doesn't care. My code will not fail
FIPS certification just because I do compact representation with some 
protocol.
I agree with Andrey Jivsov: there shouldn't be any FIPS issue here.

> Similarly, compressed representation seems not as widely supported as the uncompressed representation.

   And that, I think, is a sad artifact of the early belief that ECC was 
all patented.
There was a rumor that wouldn't die that said that there was a patent on 
compressed
ECC so everyone just did uncompressed to be safe.

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

   I wish you would reconsider. There really isn't a downside to this. 
The draft
is cleaner, Nenc and Npk become the same as Nsk for all curves, and one 
no longer
needs to handle 04 prefixing anymore-- slapping on and lopping off an 
unnecessary
byte. And there are compelling reasons to accept it. The x-only 
Montgomery Ladder
would be a huge speed advantage, and it would make HPKE better for 
certain use
cases like IoT.

   At the very least you could add 3 more KEMs that use the NIST curves with
x-only and indicate that Nenc, Npk, and Nsk are all the same for these 
KEMs and
add some verbage in 7.1.1 talking about (de)serialization of the public keys
for these KEMs. Although I would prefer only x-only (that way all the curves
look the same and it's cleaner) I guess this would be an acceptable 
alternative.

   regards,

   Dan.

> 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
>>
> _______________________________________________
> CFRG mailing list
> [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