Re: [Cfrg] hpke encoding of DH output

Dan Harkins <> Mon, 24 August 2020 07:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A194D3A088A for <>; Mon, 24 Aug 2020 00:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.948, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MjeUJqjA4UDh for <>; Mon, 24 Aug 2020 00:03:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5FE03A0890 for <>; Mon, 24 Aug 2020 00:03:51 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <> for; Mon, 24 Aug 2020 02:03:51 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <> for; Mon, 24 Aug 2020 00:02:49 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Mon, 24 Aug 2020 00:02:49 -0700
Date: Mon, 24 Aug 2020 00:03:50 -0700
From: Dan Harkins <>
In-reply-to: <>
To: Stephen Farrell <>, "" <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO Dans-MacBook-Pro.local)
References: <>
X-PMAS-Software: PreciseMail V3.3 [200820] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [Cfrg] hpke encoding of DH output
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Aug 2020 07:03:53 -0000

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

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