Re: [Cfrg] hpke encoding of DH output

[Dan Harkins <[e-mail]>]

On 8/20/20 11:03 AM, Stephen Farrell wrote:
> 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.

   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.

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

   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.