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" :
> If the WG agrees with this change, I've put together a PR
Thanks for doing the text.
Russ
On May 19, 2016, at 3:22 PM, David Benjamin wrote:
> 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 wrote:
> Reviving this thread, I also think i
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
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 rathe
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
pa
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 N
Bill Cox writes:
>I spent 2 weeks last year tracking down a flaky bug that only occurs once in
>every 256 connection: the leading 0 byte was no longer being stripped in a
>code change I ported from OpenSSL master, and only Maria DB ran random tests
>enough to trigger this condition.
My self-test
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. Furthe
