On 10/14/13 11:19 AM, Xuelei Fan wrote:
CC security-dev.
On 10/14/2013 11:04 AM, Xuelei Fan wrote:
Normally, there are only leading zero of DH keys.
Oops, typo here:
... there are only one leading zero of DH keys.
Xuelei
By the fix, I suppose
it should rally happen for 3 bytes leading zeros. The worst cases,
dh_p, dh_g and dh_Ys each has 3 leading zeros (9 bytes in total) in a
handshaking message.
I guess they are independent? So the probably of all 3 having 3 leading
zeroes is still (256^3)^3.
It's both OK to me to use 2 (6 in totla) and 3 (9 in total) leading zeros.
Any is OK, since the expected differences are big enough. Your code
change is fine.
Thanks
Max
Xuelei
On 10/14/2013 10:57 AM, Weijun Wang wrote:
Isn't 9 too big here? If I understand correctly, the probability of the
bias being up to 9 is (1/256)^9. If this happens, you should really
suspect the quality of your RNG.
Thanks
Max
On 10/14/13 10:42 AM, Xuelei Fan wrote:
Hi Max,
Please review this simple fix of a regression test intermittent failure.
webrev: http://cr.openjdk.java.net/~xuelei/8026119/webrev.00/
The cause of the issue is that during TLS handshaking, if the negotiated
DH key starts with zero bytes, the leading zero bytes are stripped in
the communication. As result in that we cannot estimate the DH key size
in handshaking messages exactly. This fix is an effort to minimum the
impact the leading zeros by a length bias. If the message size is
between [dh_key_size - bias, dh_key_size], the message is OK in this
test.
Thanks,
Xuelei
