Subject: Re: [CFRG] compact representation and HPKE

From: Dan Harkins <[email-masked]>
Date: Mon, 08 Feb 2021 14:42:22 -0800

Hello again,

   I'd like to resurrect this before it becomes "it's too late to make 
changes
that affect the wire". I created a pull request on github some time ago but
it's been ignored so let me try again here (we still technically do our work
on mailing lists).

   When I brought it up initially there was a +1 and, as Mike notes, the
y-coordinate is not needed. This 04 || x || y format for a key is just some
ancient Certicom proposal and there's really no reason to perpetuate that.

   The y-coordinate is extraneous. Getting rid of it for the NIST curves 
will
make the API much cleaner and consistent.

   This will reduce the size of the serialized public key by more than 50%
and for apps that care about such things this would be a tremendous
improvement.

   Richard noted that one can lop off the 04 and the y-coordinate after
serialization and pass x alone as part of the app using HPKE and then have
the other size reconstruct it (with either y since the sign doesn't
matter) before passing it on to be deserialized. While technically true,
that completely defeats the whole point of formalizing this process.

   In my pull request I noted that it does change the test vectors and that
I would be happy to generate them. Well, I did it. I have new test vectors
(based on -07) and will happily contribute them if asked. If the test 
vectors
get changed again (with a new version string) I can reproduce new ones minus
the y-coordinate in a matter of minutes.

   Please consider this request. There is no downside to it.

   regards,

   Dan.

On 11/6/20 4:44 PM, Dan Harkins wrote:
>
>   Yes, this is exactly right. The y-coordinate is not needed for these 
> KEMs
> as the sign is unimportant.
>
>   The spec will be simpler and the interface more uniform if you do this.
>
>   The whole point of HPKE is to make a callable API out of this 
> process that
> had been done ad hoc. Requiring a app that is taking advantage of this 
> API
> to take the output of the API and parse through it, throwing away one half
> of one of the output strings and lopping off the first octet, is defeating
> the whole purpose and is expecting a lot. The more this is a black box the
> better.
>
>   regards,
>
>   Dan.
>
> On 11/6/20 3:19 PM, Mike Hamburg wrote:
>> Hello Richard,
>>
>> I haven’t paid much attention to HPKE, so it’s likely I’m missing 
>> something here, but why not use the x-only Montgomery ladder on NIST 
>> curves?  That’s the fastest and simplest approach, and it can operate 
>> with or without the y-coordinates.
>>
>> Also, some implementations do not compute both the x- and 
>> y-coordinates, and it would be more convenient not to compute or send 
>> even a sign bit if you’re intending to use an x-only ladder.
>>
>> Cheers,
>> — Mike
>>
>>> On Nov 6, 2020, at 10:19 PM, Richard Barnes <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Nothing about this says that you have to *send* the keys 
>>> uncompressed.  You can use whatever representation you want on the 
>>> wire.  You just have to decompress them before you put them into the 
>>> key schedule. Which you're probably doing anyway, because you need 
>>> both coordinates to do point multiplication with these curves.  So I 
>>> am inclined not to make this change.
>>>
>>> --Richard
>>>
>>> On Fri, Nov 6, 2020 at 4:52 PM John Mattsson 
>>> <john.mattsson=[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>     +1
>>>
>>>     Sending the keys uncompressed makes HPKE unsuitable for
>>>     constrained IoT.
>>>
>>>     -----Original Message-----
>>>     From: CFRG <[email-masked]
>>>     <mailto:[email-masked]>> on behalf of Dan Harkins
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     Date: Friday, 6 November 2020 at 21:00
>>>     To: CFRG <[email-masked] <mailto:[email-masked]>>
>>>     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
>>>     [email-masked] <mailto:[email-masked]>
>>>     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
>>>
>>>     _______________________________________________
>>>     CFRG mailing list
>>>     [email-masked] <mailto:[email-masked]>
>>>     https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>> _______________________________________________
>>> CFRG mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>> _______________________________________________
>> CFRG mailing list
>> [email-masked]
>> 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
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> 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

---

From: John Mattsson <[email-masked]>
Date: Wed, 10 Feb 2021 11:59:41 +0000

Great work Dan. I strongly think this is the way to go. Forcing implementations to calculate a not needed y-coordinate would be strange.

Cheers,
John

From: CFRG <[email-masked]> on behalf of Dan Harkins <[email-masked]>
Date: Monday, 8 February 2021 at 23:42
To: "[email-masked]" <[email-masked]>
Subject: Re: [CFRG] compact representation and HPKE

  Hello again,

  I'd like to resurrect this before it becomes "it's too late to make changes
that affect the wire". I created a pull request on github some time ago but
it's been ignored so let me try again here (we still technically do our work
on mailing lists).

  The y-coordinate is extraneous. Getting rid of it for the NIST curves will
make the API much cleaner and consistent.

(based on -07) and will happily contribute them if asked. If the test vectors

  regards,

  Dan.

  Yes, this is exactly right. The y-coordinate is not needed for these KEMs
as the sign is unimportant.

  The whole point of HPKE is to make a callable API out of this process that
had been done ad hoc. Requiring a app that is taking advantage of this API
to take the output of the API and parse through it, throwing away one half
of one of the output strings and lopping off the first octet, is defeating
the whole purpose and is expecting a lot. The more this is a black box the
better.

  regards,

  Dan.

I haven’t paid much attention to HPKE, so it’s likely I’m missing something here, but why not use the x-only Montgomery ladder on NIST curves?  That’s the fastest and simplest approach, and it can operate with or without the y-coordinates.

Also, some implementations do not compute both the x- and y-coordinates, and it would be more convenient not to compute or send even a sign bit if you’re intending to use an x-only ladder.

Cheers,
— Mike

On Nov 6, 2020, at 10:19 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

Nothing about this says that you have to *send* the keys uncompressed.  You can use whatever representation you want on the wire.  You just have to decompress them before you put them into the key schedule. Which you're probably doing anyway, because you need both coordinates to do point multiplication with these curves.  So I am inclined not to make this change.

--Richard

On Fri, Nov 6, 2020 at 4:52 PM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:
+1

Sending the keys uncompressed makes HPKE unsuitable for constrained IoT.

-----Original Message-----
From: CFRG <[email-masked]<mailto:[email-masked]>> on behalf of Dan Harkins <[email-masked]<mailto:[email-masked]>>
Date: Friday, 6 November 2020 at 21:00
To: CFRG <[email-masked]<mailto:[email-masked]>>
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.

   regards,

   Dan.

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
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

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=8e4205de-d1d93cdc-8e424545-869a14f4b08c-465b9e5abce36ec9&q=1&e=a61452db-e5d8-46d2-b87b-d0f281c2fac8&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>
_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=7a0c280b-25971109-7a0c6890-869a14f4b08c-9306a6e8c390632d&q=1&e=a61452db-e5d8-46d2-b87b-d0f281c2fac8&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

CFRG mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=66576edf-39cc57dd-66572e44-869a14f4b08c-8204a953b7ece8f9&q=1&e=a61452db-e5d8-46d2-b87b-d0f281c2fac8&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

--

CFRG mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=9c603329-c3fb0a2b-9c6073b2-869a14f4b08c-2a44603a4c6091cb&q=1&e=a61452db-e5d8-46d2-b87b-d0f281c2fac8&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

--

---

From: Michael Scott <[email-masked]>
Date: Wed, 10 Feb 2021 12:28:20 +0000

Well, there is a minor downside - the recipient has to do some extra work
(a modular square root) to reconstitute the y coordinate.

For an enfeebled recipient this might be quite onerous.

Mike

On Mon, Feb 8, 2021 at 10:42 PM Dan Harkins <[email-masked]> wrote:

> curves?  That’s the fastest and simplest approach, and it can operate with
> or without the y-coordinates.
>
> Also, some implementations do not compute both the x- and y-coordinates,
> and it would be more convenient not to compute or send even a sign bit if
> you’re intending to use an x-only ladder.
>
> Cheers,
> — Mike
>
> On Nov 6, 2020, at 10:19 PM, Richard Barnes <[email-masked]> wrote:
>
> Nothing about this says that you have to *send* the keys uncompressed.
> You can use whatever representation you want on the wire.  You just have to
> decompress them before you put them into the key schedule. Which you're
> probably doing anyway, because you need both coordinates to do point
> multiplication with these curves.  So I am inclined not to make this change.
>
> --Richard
>
> On Fri, Nov 6, 2020 at 4:52 PM John Mattsson <john.mattsson=
> [email-masked]> wrote:
>
>> +1
>>
>> To: CFRG <[email-masked]>
> CFRG mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
> --
> CFRG mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
> --

---

From: Michael Scott <[email-masked]>
Date: Wed, 10 Feb 2021 12:29:38 +0000

... but then again if y is definitely not needed, maybe there truly is no
downside.

Mike

---

From: Dan Harkins <[email-masked]>
Date: Wed, 10 Feb 2021 04:42:44 -0800

For all of these curves, p = 3 mod 4 so doing a modular square root 
is just
exponentiation to (p + 1)/4. Not sure how onerous an additional 
exponentiation
is.

   But then Mike Hamburg was saying that one can do a x-only Montgomery 
Ladder
for these curves if an exponentiation is, indeed, onerous so there are
options to consider.

   Really, there isn't a downside. We get a cleaner and more consistent 
API,
and less cruft required to be exported/imported.

   regards,

   Dan.

On 2/10/21 4:29 AM, Michael Scott wrote:
> ... but then again if y is definitely not needed, maybe there truly is 
> no downside.
>
> Mike
>
> On Wed, Feb 10, 2021 at 12:28 PM Michael Scott <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Well, there is a minor downside - the recipient has to do some
>     extra work (a modular square root) to reconstitute the y coordinate.
>
>     On Mon, Feb 8, 2021 at 10:42 PM Dan Harkins <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>           Hello again,
>
>>>         I haven’t paid much attention to HPKE, so it’s likely I’m
>>>         missing something here, but why not use the x-only
>>>         Montgomery ladder on NIST curves?  That’s the fastest and
>>>         simplest approach, and it can operate with or without the
>>>         y-coordinates.
>>>
>>>         y-coordinates, and it would be more convenient not to
>>>         compute or send even a sign bit if you’re intending to use
>>>         an x-only ladder.
>>>
>>>         Cheers,
>>>         — Mike
>>>
>>>>         uncompressed. You can use whatever representation you want
>>>>         on the wire.  You just have to decompress them before you
>>>>         put them into the key schedule. Which you're probably doing
>>>>         anyway, because you need both coordinates to do point
>>>>             <mailto:[email-masked]>> on behalf of Dan
>>>>             Harkins <[email-masked] <mailto:[email-masked]>>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 10 Feb 2021 19:24:29 +0100

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 <[email-masked]> wrote:
> 
> 
>   Hello,
>

---

From: Dan Harkins <[email-masked]>
Date: Wed, 10 Feb 2021 10:36:50 -0800

Hi Benjamin,

> I guess you can certainly use some compressed form for transport in that case...

   Many other uses require that both sides agree on the sign and therefore
either the point is sent uncompressed or as the x-coordinate plus a sign 
bit.
But in this case we don't care about the sign. We are doing "compact output"
(per RFC 6090) and therefore can take advantage of "compact representation"
(ibid).

   regards,

   Dan.

---

From: Loup Vaillant-David <[email-masked]>
Date: Thu, 11 Feb 2021 00:11:59 +0100

On Wed, 2021-02-10 at 04:42 -0800, Dan Harkins wrote:
> is just exponentiation to (p + 1)/4. Not sure how onerous an
> additional exponentiation is.

I've just checked by removing the final inversion from my X25519
implementation (which uses an x-only ladder), the cost is less than
10%. Comparatively even less if you're using a more expensive ladder.

> Ladder for these curves if an exponentiation is, indeed, onerous so
> there are options to consider.

To be checked, but an x-only ladder is likely to be faster on its own.
So not only do you gain speed by avoiding an exponentiation, you gain
speed by running a faster ladder.

While we *may* beat x-only ladders by using a complete addition law and
fixed windows, it would be more complex, and require more memory (stack
in most implementations). And a naive x-y ladder is about half the
speed of the x-only ladder, if not less (assuming constant time
implementations). This is horrible for embedded applications.

Alternatively, we could recover the y-coordinate *after* performing an
x-only ladder. With luck, it might not even cost an additional
exponentiation. Still, this feels like an avoidable complication, not
worth the single bit of security you could get by recovering the sign
of a point.

As an implementer, I have a very strong preference for x-only ladders:
not only are they fast, they're easiest to implement. Less room for
error.

Loup.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Feb 2021 13:10:24 -0800

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.

-Ekr

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 12 Feb 2021 13:40:02 -0800

On Fri, Feb 12, 2021, at 1:10 PM, Eric Rescorla wrote:
> (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).
> 
> 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, (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 (c) not FIPS compliant. Similarly, compressed representation seems not as widely supported as the uncompressed representation. 

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

Best,
Chris

[1] https://tools.ietf.org/html/draft-jivsov-ecc-compact-05

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 12 Feb 2021 13:59:39 -0800

On 12 Feb 2021, at 13:40, Christopher Wood wrote:

> (I don't think RFC 6090 or the related expired draft [1] rise to the 
> level of a standard format)>

For those of you who were not here a decade ago:

- RFC 6090 was never meant to be a standard. It was written and 
published to show that there was ample prior art for elliptic curves 
against some patent concerns that people had. To a large extent, it met 
that goal and discussions of ECC stopped ending with "but what about the 
patents", then they stopped having patents come up at all.

- draft-jivsov-ecc-compact was not related to RFC 6090.

--Paul Hoffman

---

From: Dan Harkins <[email-masked]>
Date: Fri, 12 Feb 2021 14:00:24 -0800

On 2/12/21 1:10 PM, Eric Rescorla wrote:
> 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."

   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 <[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Feb 2021 22:11:14 +0000

Hiya,

>> to move to CFRG curves anyway, which are already in the technically 

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.

>>     --     "The object of life is not to be on the side of the 
>> majority, but to

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Feb 2021 14:13:32 -0800

On Fri, Feb 12, 2021 at 2:00 PM Dan Harkins <[email-masked]> wrote:

> which uses x-coordinate-only form for CFRG curves but uncompressed form for
> NIST 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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Feb 2021 22:18:50 +0000

Probably obvious but...

> PITA to use those and would mean you could do HPKE with a

s/could/couldn't/ above ;-)

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 12 Feb 2021 14:29:38 -0800

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

---

From: Mike Hamburg <[email-masked]>
Date: Fri, 12 Feb 2021 18:32:55 -0400

> On Feb 12, 2021, at 5:59 PM, Paul Hoffman <[email-masked]> wrote:
> 
>> (I don't think RFC 6090 or the related expired draft [1] rise to the level of a standard format)>
> - RFC 6090 was never meant to be a standard. It was written and published to show that there was ample prior art for elliptic curves against some patent concerns that people had. To a large extent, it met that goal and discussions of ECC stopped ending with "but what about the patents", then they stopped having patents come up at all.

It’s worth mentioning, on the subject of “but what about the patents”: the fastest set of x-only formulas I’m aware of, 11M/bit as described in https://eprint.iacr.org/2020/437.pdf <https://eprint.iacr.org/2020/437.pdf>, are patented by my employer (not my choice to make).  On the second-fastest set I’m aware of, 12M/bit as described in https://ches.2017.rump.cr.yp.to/a1933e522beb16591d9dc8e373ad7079.pdf <https://ches.2017.rump.cr.yp.to/a1933e522beb16591d9dc8e373ad7079.pdf>, I’m not aware of any patents.

As for HPKE: I’m always sad to see a technically better solution passed up, especially since I’ve done so much research to improve it.  But if it’s not standardized or widely supported at all yet, then a decision to use the existing structures makes sense.  I’m actually pretty surprised that it’s not standardized anywhere: it’s weird that everyone uses x-only output with short Weierstrass curves, but nobody uses x-only wire formats with them.

For FIPS: would HPKE be FIPS-compliant anyway?  Don’t FIPS-compliant ECC private keys have to be generated directly from an approved DRBG, or something like that?

Regards,
— Mike

---

From: Mike Hamburg <[email-masked]>
Date: Fri, 12 Feb 2021 18:35:54 -0400

> On Feb 12, 2021, at 6:32 PM, Mike Hamburg <[email-masked]> wrote:

> It’s worth mentioning, on the subject of “but what about the patents”: the fastest set of x-only formulas I’m aware of, 11M/bit as described in https://eprint.iacr.org/2020/437.pdf <https://eprint.…

To clarify, “fastest” here is restricted to general short-Weierstrass curves over large-characteristic fields, without endomorphisms, etc.  The classic Montgomery ladder on Montgomery curves is of course faster.

— Mike

---

From: Loup Vaillant-David <[email-masked]>
Date: Sat, 13 Feb 2021 00:06:46 +0100

> compressed form for NIST curves, 
> [...]
> for me, this isn't a case of encouraging cfrg curves but rather

Not quite sure what you meant, but I am extremely wary of making things
"simpler" by taking on gigantic dependencies such as OpenSSL.

We need to consider the complexity of the whole system, as if we were
rewriting everything from scratch. Because over time, bit by bit, we
eventually will.

Loup.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 12 Feb 2021 23:45:52 +0000

It’s worth mentioning, on the subject of “but what about the patents”: the fastest set of x-only formulas I’m aware of, 11M/bit as described in https://eprint.iacr.org/2020/437.pdf<https://urldefense.com/v3/__https:/eprint.iacr.org/2020/437.pdf__;!!GjvTz_vk!FoLmklnd1IErYIx7e46VOa9x2Cj5Jvv895r5cwj6uatd6n8t7kxFcVbeGijZ$>, are patented by my employer (not my choice to make

Should someone file an IPR disclosure on this?

---

From: Mike Hamburg <[email-masked]>
Date: Fri, 12 Feb 2021 20:06:16 -0400

> On Feb 12, 2021, at 7:45 PM, Salz, Rich <[email-masked]> wrote:
> 
> It’s worth mentioning, on the subject of “but what about the patents”: the fastest set of x-only formulas I’m aware of, 11M/bit as described in https://eprint.iacr.org/2020/437.pdf <https://urldefense.com/v3/__https:/eprint.iacr.org/2020/437.pdf__;!!GjvTz_vk!FoLmklnd1IErYIx7e46VOa9x2Cj5Jvv895r5cwj6uatd6n8t7kxFcVbeGijZ$>, are patented by my employer (not my choice to make
>  

Possibly.  I’ll look into it next week… I’m not here on behalf of my employer, but I should probably check with their lawyers since it’s their IP.  — Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Feb 2021 00:41:52 +0000

Hiya,

> "simpler" by taking on gigantic dependencies such as OpenSSL.

Wasn't that, no. My implementation uses OpenSSL and I didn't
find a way to do what Dan suggests using the obvious higher
level OpenSSL APIs.

In the meantime, Dan tells me offlist that his OpenSSL code
does use such a way, which is great, so I'll take a peek and
get back in a few days, likely to admit he knows more about
all this than me (but I knew that was true before I started:-)

So if there's no real difficulty in implementing what Dan
suggests, I'd be fine with it. If OTOH, it makes it harder
to implement (my position before I take that peek at his
code:-), then I'll continue to be against the change.

Cheers,
S.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 13 Feb 2021 08:45:52 +0000

Dan Harkins <[email-masked]> writes:

>We should go with the "technically superior approach", especially when that
>results in a cleaner and more consistent API for HPKE.

If you're proposing we mandate a switch from a form that everyone uses and
everything supports to one that no-one uses and that (virtually) nothing
supports then that's not a "technically superior approach", it's "workgroup
posturing".  

For an example of where that leads, look at what happened with the S/MIME WG
and their mandating of static-ephemeral DH in place of RSA.

Peter.

---

From: John Mattsson <[email-masked]>
Date: Sat, 13 Feb 2021 11:55:43 +0000

Hi,

Note that sending a useless y-coordiate on the wire is the reason why integrity protection of pKE is needed to provide IND-CCA2 for the NIST P-curves. This is one of the bad ideas from previous ECIES standards that I hoped (and still hope) HPKE will get rid off.

I think we should differentiate between:
- Wire format
- API in crypto libraries
- Algorithm format

The wire format does not need to the the same as the API format which does not need to be the same as the format used by the algorithm. The API format in libraries can be (y,x), (sign, x) or (x). I think HPKE needs to be able to work with all three of these library API formats.

I think that x-coordinate only is clearly the superior wire format. Just like Andey Jisov, I do not see any big interface problems with either approach.

I strongly oppose uncompressed being the only allowed wire format. That would make HPKE completely unsuitable for any wireless use cases. I hope that HPKE can eventually be used in 3GPP 5G. I would also want to use it for various IoT use cases. Let's not publish another CFRG RFC that ignores IoT and wireless.

I think compressed format as wire format is a mishmash that nobody really wants. Maybe HPKE needs to allow several wire formats.

Mike Hamburg wrote:
>I’m actually pretty surprised that it’s not standardized anywhere
FYI, EHDOC (draft-ietf-lake-edhoc) is planning to compact representation as the wire representation for all curves.

Cheers,
John

-----Original Message-----
From: CFRG <[email-masked]> on behalf of Peter Gutmann <[email-masked]>
Date: Saturday, 13 February 2021 at 09:46
To: Dan Harkins <[email-masked]>, Eric Rescorla <[email-masked]>
Cc: CFRG <[email-masked]>
Subject: Re: [CFRG] compact representation and HPKE

Peter.

_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=9d140697-c28f3e75-9d14460c-86073b36ea28-8b3931cdae1bc72b&q=1&e=2fe8f2e2-6e0c-4362-a941-cebe452a212a&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: Benjamin Lipp <[email-masked]>
Date: Sat, 13 Feb 2021 12:50:01 +0000 (UTC)

Hi,

> Note that sending a useless y-coordiate on the wire is the reason why integrity protection of pKE is needed to provide IND-CCA2 for the NIST P-curves. This is one of the bad ideas from previous ECI…

HPKE's DHKEM includes pkE and pkR (and pkS) in the context of the key derivation:

kem_context = concat(enc, pkRm)
shared_secret = ExtractAndExpand(dh, kem_context)

(enc is the serialization of pkE)

Does this mitigate the attack on IND-CCA2 that you have in mind?

Best,
Benjamin

---

From: John Mattsson <[email-masked]>
Date: Sat, 13 Feb 2021 13:58:55 +0000

Thanks Benjamin,

I know it does. I did not intend to indicate that HPKE suffers from this, I just wanted to point out that this solution in ECIES systems is strange, and that the straightforward solution is to remove the malleable information that is not used anyway.

A long time ago, I think I promised on the CFRG list to suggest text stating that HPKE does not suffer from what SECG calls benign malleability. I just made a PR for this.

https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/205

-----Original Message-----
From: CFRG <[email-masked]> on behalf of Benjamin Lipp <[email-masked]>
Date: Saturday, 13 February 2021 at 13:50
To: "[email-masked]" <[email-masked]>
Subject: Re: [CFRG] compact representation and HPKE

Hi,

Best,
Benjamin

_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=17732f8f-48e8176d-17736f14-86073b36ea28-d0074ee430b256b3&q=1&e=596d9075-1e9d-4038-9335-766b5aa8ecb2&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: Mike Hamburg <[email-masked]>
Date: Sun, 14 Feb 2021 11:58:04 -0400

> Should someone file an IPR disclosure on this?

On further review, it looks to me like an IPR disclosure is not appropriate here, because the patented ladder wouldn’t be the only way to implement x-only HPKE (which was the point of my comment).

But this is a good lesson about not mentioning patents on mailing lists.

Regards,
— Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 14 Feb 2021 19:25:47 +0000

*   On further review, it looks to me like an IPR disclosure is not appropriate here, because the patented ladder wouldn’t be the only way to implement x-only HPKE (which was the point of my comment).

Thanks, that makes sense to me.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 15 Feb 2021 00:07:01 -0800

Hi Chris,

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

---

From: Karthik Bhargavan <[email-masked]>
Date: Mon, 15 Feb 2021 17:44:33 +0100

I think the idea of having a compact representation of EC points for use in IoT-like scenarios is an attractive one, but the core ciphersuites of HPKE should only depend on standardized and widely-implemented point formats.

In particular, HPKE is certainly not the right place to standardize a new EC point format, however sensible the change may seem.
A protocol like EDHOC is laser-focused on small wire messages and is meant to be implemented by IoT-specific crypto libraries, and so it makes sense for that protocol to employ such optimizations.
Perhaps the LAKE working group could drive a IETF/CFRG standard for x-only EC point representations that are more generally usable by other protocols?

Having said all that, HPKE is extensible and we do anticipate extensions to HPKE in the near future, notably for adding PQ ciphersuites.
I think the best way to proceed for compact HPKE would be, along the lines of Dan’s suggestion, to propose new KEM algorithm identifiers for compact encodings of the NIST curves, and to do this as part of a new CFRG draft as an extension to HPKE.
I suspect that, beyond the point representation, we may find other parts of HPKE that would benefit from compaction for low-bandwidth scenarios.

Best,
Karthik

---

From: Richard Barnes <[email-masked]>
Date: Mon, 15 Feb 2021 11:50:45 -0500

Hi folks,

I think Karthik is on the right track here.  While the compact
representation undoubtedly has its benefits, it seems like there is no
disagreement that it is not widely supported in either standards or crypto
libraries.  So there is a sizable community for whom a requirement to use
the compact format would render HPKE unusable.

Given that, I would propose we resolve this issue in the following way:
* In the current document, define KEMs for the NIST curves using the
uncompressed format.
* If there is a community that is *also* interested in supporting the
compact format, they can define new KEM code points for it.

Would folks be comfortable proceeding on that basis?

--Richard

On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan <
[email-masked]> wrote:

> I think the idea of having a compact representation of EC points for use
> in IoT-like scenarios is an attractive one, but the core ciphersuites of
> HPKE should only depend on standardized and widely-implemented point
> formats.
>
> In particular, HPKE is certainly not the right place to standardize a new
> EC point format, however sensible the change may seem.
> A protocol like EDHOC is laser-focused on small wire messages and is meant
> to be implemented by IoT-specific crypto libraries, and so it makes sense
> for that protocol to employ such optimizations.
> Perhaps the LAKE working group could drive a IETF/CFRG standard for x-only
> EC point representations that are more generally usable by other protocols?
>
> Having said all that, HPKE is extensible and we do anticipate extensions
> to HPKE in the near future, notably for adding PQ ciphersuites.
> I think the best way to proceed for compact HPKE would be, along the lines
> of Dan’s suggestion, to propose new KEM algorithm identifiers for compact
> encodings of the NIST curves, and to do this as part of a new CFRG draft as
> an extension to HPKE.
> I suspect that, beyond the point representation, we may find other parts
> of HPKE that would benefit from compaction for low-bandwidth scenarios.
>
> Best,
> Karthik
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 08:56:25 -0800

WFM.

On Mon, Feb 15, 2021 at 8:51 AM Richard Barnes <[email-masked]> wrote:

>> A protocol like EDHOC is laser-focused on small wire messages and is
>> meant to be implemented by IoT-specific crypto libraries, and so it makes
>> sense for that protocol to employ such optimizations.
>> Perhaps the LAKE working group could drive a IETF/CFRG standard for
>> x-only EC point representations that are more generally usable by other
>> protocols?
>>
>> I think the best way to proceed for compact HPKE would be, along the
>> lines of Dan’s suggestion, to propose new KEM algorithm identifiers for
>> compact encodings of the NIST curves, and to do this as part of a new CFRG
>> draft as an extension to HPKE.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Mon, 15 Feb 2021 18:14:58 +0100

I agree with that approach...
B.

> On 15 Feb 2021, at 17:50, Richard Barnes <[email-masked]> wrote:
> 
> Hi folks,
> 
> I think Karthik is on the right track here.  While the compact representation undoubtedly has its benefits, it seems like there is no disagreement that it is not widely supported in either standards or crypto libraries.  So there is a sizable community for whom a requirement to use the compact format would render HPKE unusable.
> 
> * In the current document, define KEMs for the NIST curves using the uncompressed format.  
> * If there is a community that is *also* interested in supporting the compact format, they can define new KEM code points for it.
>

---

From: Dan Harkins <[email-masked]>
Date: Mon, 15 Feb 2021 10:42:34 -0800

Hello,

On 2/15/21 8:50 AM, Richard Barnes wrote:
> disagreement that it is not widely supported in either standards or 
> crypto libraries.  So there is a sizable community for whom a 
> requirement to use the compact format would render HPKE unusable.
>

   Yes, I think this is an acceptable way forward. I can get an I-D out RSN
in the expectation that RGLC finishes and we will soon have an HPKE RFC to
update.

   regards,

   Dan.

>
> --Richard
>
> On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think the idea of having a compact representation of EC points
>     for use in IoT-like scenarios is an attractive one, but the core
>     ciphersuites of HPKE should only depend on standardized and
>     widely-implemented point formats.
>
>     In particular, HPKE is certainly not the right place to
>     standardize a new EC point format, however sensible the change may
>     seem.
>     A protocol like EDHOC is laser-focused on small wire messages and
>     is meant to be implemented by IoT-specific crypto libraries, and
>     so it makes sense for that protocol to employ such optimizations.
>     Perhaps the LAKE working group could drive a IETF/CFRG standard
>     for x-only EC point representations that are more generally usable
>     by other protocols?
>
>     Having said all that, HPKE is extensible and we do anticipate
>     extensions to HPKE in the near future, notably for adding PQ
>     ciphersuites.
>     I think the best way to proceed for compact HPKE would be, along
>     the lines of Dan’s suggestion, to propose new KEM algorithm
>     identifiers for compact encodings of the NIST curves, and to do
>     this as part of a new CFRG draft as an extension to HPKE.
>     I suspect that, beyond the point representation, we may find other
>     parts of HPKE that would benefit from compaction for low-bandwidth
>     scenarios.
>
>     Best,
>     Karthik
>

---

From: Billy Brumley <[email-masked]>
Date: Tue, 16 Feb 2021 08:39:30 +0200

> I think Karthik is on the right track here.  While the compact representation undoubtedly has its benefits, it seems like there is no disagreement that it is not widely supported in either standard…

In the case of OpenSSL, I disagree.

If you (=application developer) are dealing with points directly in
OpenSSL, you are probably already doing it wrong.

Using the correct abstractions in OpenSSL, whether a "point" has 1, 2,
3, or 42 coordinates shouldn't matter. In fact when using the correct
abstraction in OpenSSL, you shouldn't know it's a point at all. Just a
byte string.

So I support this one, in the spirit of forward thinking, rather than
propagating ideas from two decades old standards

> (1) A technically superior approach (x-coordinate only)

I would suggest soliciting an opinion from the OpenSSL OTC before
making any decision based on perceived API difficulties.

My 2c, having never even read the HPKE draft.

BBB

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 16 Feb 2021 10:35:40 +0300

Dear Dan,

>> I can get an I-D out RSN in the expectation that RGLC finishes
Just a quick comment: the RGLC (the second RGLC) was in August, see
https://mailarchive.ietf.org/arch/msg/cfrg/H2xkKDiMVM6x0B8KdGx6Ii5iOO0/,
the HPKE draft is one step before the IRSG review.

>> Yes, I think this is an acceptable way forward.
Thanks, Dan! No objections against moving forward with the HPKE draft now,
right?

Regards,
Stanislav

---

From: Dan Harkins <[email-masked]>
Date: Tue, 16 Feb 2021 01:13:27 -0800

Hi Stanislav,

> the HPKE draft is one step before the IRSG review.

   Ahhh. OK, then. Even closer.

> Thanks, Dan! No objections against moving forward with the HPKE draft 
> now, right?

   No, none at all. Thanks to the authors for consideration of this and 
finding an
acceptable way forward.

   regards,

   Dan.
> Regards,
> Stanislav
>
>
>
> On Mon, 15 Feb 2021 at 21:42, Dan Harkins <[email-masked] 
>>     representation undoubtedly has its benefits, it seems like there
>>     is no disagreement that it is not widely supported in either
>>     standards or crypto libraries.  So there is a sizable community
>>     for whom a requirement to use the compact format would render
>>     HPKE unusable.
>>
>>     * If there is a community that is *also* interested in supporting
>>     the compact format, they can define new KEM code points for it.
>>
>>         I think the idea of having a compact representation of EC
>>         points for use in IoT-like scenarios is an attractive one,
>>         but the core ciphersuites of HPKE should only depend on
>>         standardized and widely-implemented point formats.
>>
>>         standardize a new EC point format, however sensible the
>>         change may seem.
>>         A protocol like EDHOC is laser-focused on small wire messages
>>         and is meant to be implemented by IoT-specific crypto
>>         libraries, and so it makes sense for that protocol to employ
>>         such optimizations.
>>         Perhaps the LAKE working group could drive a IETF/CFRG
>>         standard for x-only EC point representations that are more
>>         generally usable by other protocols?
>>
>>         I think the best way to proceed for compact HPKE would be,
>>         along the lines of Dan’s suggestion, to propose new KEM
>>         algorithm identifiers for compact encodings of the NIST
>>         curves, and to do this as part of a new CFRG draft as an
>>         extension to HPKE.
>>         I suspect that, beyond the point representation, we may find
>>         other parts of HPKE that would benefit from compaction for
>>         low-bandwidth scenarios.
>>
>>         Best,
>>         Karthik
>>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 16 Feb 2021 16:01:28 +0300

Thanks a lot, Dan!

I am sure that it has been an important question to discuss.
No reasons to keep the draft on pause then.

Thanks again.

Regards,
Stanislav

On Tue, 16 Feb 2021 at 12:13, Dan Harkins <[email-masked]> wrote:

>>> In particular, HPKE is certainly not the right place to standardize a
>>> new EC point format, however sensible the change may seem.

---

From: John Mattsson <[email-masked]>
Date: Tue, 16 Feb 2021 15:03:43 +0000

Hi,

I also find it acceptable as long as other wire formats can be registered later. I did not realize the draft was so late in the process. I think this will be very important and useful specification.

Karthik wrote:

>Having said all that, HPKE is extensible and we do anticipate extensions to HPKE in the near >future, notably for adding PQ ciphersuites.

The Encap, Decap interfaces seems easy to adopt to PQC algoritm. Have anybody looked at how well the authenticated "AuthEncap and AuthDecap interfaces works for the NIST PQC finalists?

>Perhaps the LAKE working group could drive a IETF/CFRG standard for x-only EC point representations >that are more generally usable by other protocols?

That could be a posibility, but maybe it would be even better with a IRTF draft? Seems to be quite a lot of CRFG people wanting compact representation.

Cheers,
John

From: CFRG <[email-masked]> on behalf of "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tuesday, 16 February 2021 at 14:02
To: Dan Harkins <[email-masked]>
Cc: Karthik Bhargavan <[email-masked]>, CFRG <[email-masked]>
Subject: Re: [CFRG] compact representation and HPKE

Thanks a lot, Dan!

Thanks again.

Regards,
Stanislav

On Tue, 16 Feb 2021 at 12:13, Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hi Stanislav,

>> I can get an I-D out RSN in the expectation that RGLC finishes
Just a quick comment: the RGLC (the second RGLC) was in August, see https://mailarchive.ietf.org/arch/msg/cfrg/H2xkKDiMVM6x0B8KdGx6Ii5iOO0/, the HPKE draft is one step before the IRSG review.

>> Yes, I think this is an acceptable way forward.
Thanks, Dan! No objections against moving forward with the HPKE draft now, right?

  No, none at all. Thanks to the authors for consideration of this and finding an
acceptable way forward.

  regards,

  Dan.

Regards,
Stanislav

On Mon, 15 Feb 2021 at 21:42, Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

  Hello,

  regards,

  Dan.

--Richard

On Mon, Feb 15, 2021 at 11:45 AM Karthik Bhargavan <[email-masked]<mailto:[email-masked]>> wrote:
I think the idea of having a compact representation of EC points for use in IoT-like scenarios is an attractive one, but the core ciphersuites of HPKE should only depend on standardized and widely-implemented point formats.

Best,
Karthik

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=4c93a7ae-13089eea-4c93e735-861d41abace8-64fc0b181f5dc6af&q=1&e=6c12a030-2f37-451a-b179-a7c0cb9b4818&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

--

escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=d8b66e3c-872d5778-d8b62ea7-861d41abace8-fe29b8aab75b9699&q=1&e=6c12a030-2f37-451a-b179-a7c0cb9b4818&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

--

---

From: denis bider <[email-masked]>
Date: Tue, 16 Feb 2021 22:13:24 -0600

I really dislike this sort of idealism, it's like purporting that proper
communism simply hasn't been tried yet.

In theory, a cryptographic library would implement a high-level interface
that (1) covers the way an algorithm is used in the protocol you're
implementing, (2) covers all the niche cases of use in that protocol.

In practice, the cryptographic (1) has some well-intended high-level
interfaces, which happen to not support the exact way the algorithm is used
in the protocol you're implementing, or (2) it doesn't cover all the niche
cases of use in that protocol.

So, as is the case with most abstractions, eventually you realize that you
have to bypass the abstraction and go to the nuts and bolts. Your life is
made much easier that way.

Cases in point:

- Windows CNG implements nice abstractions for DH and ECDH, and since these
abstractions are so nice and safe, there is no way provided to access the
agreed value. Instead you have a bunch of computations you can apply to the
agreed value, which works for protocols like TLS.

But none of those functions work for SSH. So how do you get the agreed
value for SSH? Trade secret that involves accessing internal Windows CNG
structures which have changed multiple times as Windows is auto-updated,
requiring the software to be updated as well.

- In the case of OpenSSL, the easiest way I've found to initialize an
ECDSA/secp256k1 public key from its SSH encoding is by
calling EC_KEY_set_public_key_affine_coordinates, which involves BN_bin2bn
to convert x and y.

There may be a more "kosher" way, but this works and fits my usage.

So. I really dislike "but the proper way to use it is our well-meant
high-level abstraction", cause it boils down to a design for hypothetical
theory instead of for useful practice.

denis