Subject: [Cfrg] hpke encoding of DH output

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2020 19:03:26 +0100

Hi,

I ran into an interop problem with draft-05 that I think is
worth bringing to the list.

Draft-05 says:

"For the variants of DHKEM defined in this document, the
size Ndh of the Diffie-Hellman shared secret is equal to
Npk, and the size Nsecret of the KEM shared secret is equal
to the output length of the hash function underlying the
KDF."

What that means is that, for the NIST curves, the DH
value (used to be zz I think) is represented as a public
key in uncompressed form. My code uses the OpenSSL
EVP_PKEY_derive() function (same as it did for draft-02)
which only gives me the X co-ordinate, and OpenSSL doesn't
seem to have an easy way to get the uncompressed version
from that. I don't know, but I'd guess that other libraries
might be similar. In draft-02 only the X co-ordinate was
used btw, and I don't recall this change being brought
up on the list.

I don't think there's any security benefit in treating
the output of the DH operation as a public key. If there
were, then I'd be fine with changing to use lower level
calls to do the DH operation. But that seems a bit wrong,
so I'd argue that we'd be better to not treat the DH
shared secret value as a public key when encoding that.

Separately, it'd be good to add those values to the
test vectors - took me a while to find this - in the
end I had to add more tracing to the go implementation
to spit out these values.

Lastly, even if we don't make a change, it'd be good
to add text to clarify this, but I think I'd prefer we
make the change if there's no security downside.

Cheers,
S.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Aug 2020 14:29:50 -0400

Hi Stephen,

I think you're right here.  I just re-checked both the NIST and SECG
specifications for ECDH [1][2], and they're in agreement that the secret
value is the X-coordinate.  I'll work with my coauthors to get this
implemented.

--Richard

[1] Section 5.7.1.2 of
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf
[2] Section 3.3.1 of https://www.secg.org/sec1-v2.pdf

On Thu, Aug 20, 2020 at 2:04 PM Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 20 Aug 2020 11:43:16 -0700

On Thu, Aug 20, 2020, at 11:29 AM, Richard Barnes wrote:
> specifications for ECDH [1][2], and they're in agreement that the 
> secret value is the X-coordinate.  I'll work with my coauthors to get 
> this implemented.

A proposed fix is here:

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

Thanks,
Chris

> On Thu, Aug 20, 2020 at 2:04 PM Stephen Farrell 
> <[email-masked]> wrote:
> > 
> > Hi,
> >

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2020 19:47:50 +0100

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

LGTM, thanks both.

S.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 24 Aug 2020 00:03:50 -0700

> used btw, and I don't recall this change being brought

   If you used EC_POINT_mul() with the the received public key and
your private key you'd get a point that you could then use with
EC_POINT_get_affine_coordinates() to get the x and/or y coordinates
as BIGNUMs.

> shared secret value as a public key when encoding that.

   This is what RFC 6090 refers to as "compact output" (which
is not the same as "compact representation"). The thing to keep
in mind, though, is that the x-coordinate should not be used
directly as a key because it is not generated uniformly over
the number space (it's an x-coordinate that produces a valid
y-coordinate using the equation of the curve and not all numbers
would do that), but HKDF() will take care of that quite nicely
for you.

   Dan.