Re: [CFRG] compact representation and HPKE

>
> The problem is that this comes at a less clean and consistent API for the
> underlying cryptographic primitives which then have to be different
> depending on which protocol they are embedded in.

I am not seeing a big interface problem here.

With methods discussed here, and all in
https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html, compression is
the act of removing the leading byte and y. This is trivial and doesn't
need crypto awareness.

The decompression can be based on the size of input (field size, v.s. 2x+1
field size).

Also, I am not sure there is any FIPS compliance issue here, at least with
my draft. FIPS protocols hash only x, and y can/should be reconstructed
anyway. Key generation, for cases where this matters, can be done as a
blackbox, e.g. this works with any FIPS 140-2 Level 3 compliant HSM device,
with non-extractable keys, without any awareness on the part of HSM.

On Fri, Feb 12, 2021 at 2:14 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Feb 12, 2021 at 2:00 PM Dan Harkins <dharkins@lounge.org> 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 see. So we go with the technically inferior approach, in order to
>> "encourage people
>> to move to the CFRG curves."
>>
>
> I don't think that this reflects a fair reading of what I wrote above, and
> in any case is not what I meant. Rather what I am trying to say is that we
> should weigh the costs of having an inferior interface to the NIST curves
> less heavily because we want people to move to CFRG curves anyway, at which
> point this will be an non-issue.
>
>
>   We should go with the "technically superior approach", especially when
>> that results
>> in a cleaner and more consistent API for HPKE.
>>
>
> The problem is that this comes at a less clean and consistent API for the
> underlying cryptographic primitives which then have to be different
> depending on which protocol they are embedded in.
>
> -Ekr
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>