Re: [CFRG] compact representation and HPKE

[Stephen Farrell <[e-mail]>]

Hiya,

On 12/02/2021 22:00, Dan Harkins wrote:
> 
> 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 need to check (and haven't) but IIRC for an earlier draft
I had a problem that the OpenSSL APIs didn't support the
compressed form for NIST curves, so it'd have been both a
PITA to use those and would mean you could do HPKE with a
FIPS compliant implementation IIUC. (Note: I could be
recalling wrong, and if so, apologies, but if not...) for
me, this isn't a case of encouraging cfrg curves but rather
one of enabling simpler and more broad implementation.

Cheers,
S.

> 
>    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
>>
> 
> 
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>