Re: [TLS] Diffie-Hellman: value of Z - the shared secret

Hi David,

Great. Thanks for following up on this!

I think I now understand why the implementation of DH seemed buggy in one
of the crypto libraries that I was reviewing.

Regards,
Maarten
Op 19 mei 2016 21:22 schreef "David Benjamin" <davidben@chromium.org>:

> If the WG agrees with this change, I've put together a PR here:
> https://github.com/tlswg/tls13-spec/pull/462
>
> On Tue, May 17, 2016 at 4:14 PM David Benjamin <davidben@chromium.org>
> wrote:
>
>> Reviving this thread, I also think it would also be a good idea if 1.3
>> did not stripping zeros from Z. Having this logic is rather dubious w.r.t.
>> treating secret data in constant-time. And as Bill Cox mentioned
>> elsewhere in this thread, this odd behavior has caused interoperability
>> issues in the past.
>>
>> I don't think we have to be worried about inconsistency with 1.2 as, by
>> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE
>> is already a very different beast from TLS 1.2 DHE. At this point, the only
>> thing they meaningfully share is they happen to use the same code points.
>>
>> David
>>
>> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley <housley@vigilsec.com>
>> wrote:
>>
>>> I would prefer to always use the full, known-length byte string for Z.
>>> In my experience, it is better to know the lengths of byte strings instead
>>> of stripping leading zeroes.  The difference in the speed of the HKDF
>>> computation by omitting the leading zeros is not significant.  Alignment
>>> with NIST SP 800-56A is nice, but it is not the reason for my preference.
>>>
>>> Russ
>>>
>>>
>>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com>
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I see that the leading zero is stripped off of the value of Z (the
>>> shared secret) before it is used as input to HKDF. This seems to be
>>> compatible with TLS 1.2. Then again, it is not compatible with e.g.
>>> NISP800-56A which uses the value of Z with the same size of the prime in
>>> octets. Furthermore, it is also different with regards to handling the
>>> coordinate X as used in ECDH.
>>> >
>>> > Was this a conscious decision to keep compatibility with TLS? Has the
>>> use of the value of Z including zero octets been considered?
>>> >
>>> > Regards,
>>> > Maarten
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets