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

From: Maarten Bodewes <[email-masked]>
Date: Mon, 28 Mar 2016 17:56:44 +0200

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

---

From: Bill Cox <[email-masked]>
Date: Mon, 28 Mar 2016 09:07:09 -0700

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.

I guess I would prefer that this particular weird goober in TLS would go
away, but it would be incompatible.

Bill

On Mon, Mar 28, 2016 at 8:56 AM, Maarten Bodewes <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 29 Mar 2016 11:55:37 +0000

Bill Cox <[email-masked]> 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 code includes 1K iterations of various PKC ops in mechanisms that
are sensitive to leading-zero truncation (PGP springs to mind) to detect this.
Without this, it's mostly blind luck as to whether your self-test hits the
1/256 one that triggers the problem.  Having to design coverage tests is hard
enough, but when you need to iterate them to find problems...

Peter.