Re: [Cfrg] hpke encoding of DH output

[Stephen Farrell <[e-mail]>]

On 20/08/2020 19:43, Christopher Wood wrote:
> On Thu, Aug 20, 2020, at 11:29 AM, Richard Barnes wrote:
>> 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.
> 
> A proposed fix is here:
> 
>    https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/148

LGTM, thanks both.

S.


> 
> Thanks,
> Chris
> 
>>
>> --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 
>> <[e-mail]> 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.
>>>
>>> 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.
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>