-
Bug
-
Resolution: Won't Fix
-
P4
-
7
-
None
-
generic
-
generic
While testing DHKeyAgreement between JSAFE and Sun's providers. Both SunJCE and SunPKCS11-Solaris fail.
The reason is that JSAFE and Sun's provider behave different upon the output of generateSecret(). In this test, JSAFE always returns a byte[64] array, but Sun's provider removes leading zeroes (SunJCE uses BigInteger.toByteArray(), SunPKCS11 just calls P11Util.trimZeroes() ). PKCS#3 seems to suggest that generated secret should be (or is meant to be) as long as the prime in terms of number of octets. Since the test always uses the same parameter (64-byte prime), the output should always have the same length.
About the probability: In our experiment, repeatedly running the comparision, the first difference ranges between the 60th and 400th loop. If the output is uniformly distributed between 0 and the prime, the expected value of this number should be approx 0xC2 (which is the first byte of the prime).
I don't know why people has never reported this. Maybe they are using Java at both sides, or maybe their other side also trim the zeroes, or, maybe they are just (un)lucky enough that generated secret always starts with a non-zero byte.
Although this looks like a bug, there's a risk fixing it. If "fixed" and unfixed versions of JRE running across a network use the algorithm, there will be a probability (> 1/256) that negotiation would fail.
The reason is that JSAFE and Sun's provider behave different upon the output of generateSecret(). In this test, JSAFE always returns a byte[64] array, but Sun's provider removes leading zeroes (SunJCE uses BigInteger.toByteArray(), SunPKCS11 just calls P11Util.trimZeroes() ). PKCS#3 seems to suggest that generated secret should be (or is meant to be) as long as the prime in terms of number of octets. Since the test always uses the same parameter (64-byte prime), the output should always have the same length.
About the probability: In our experiment, repeatedly running the comparision, the first difference ranges between the 60th and 400th loop. If the output is uniformly distributed between 0 and the prime, the expected value of this number should be approx 0xC2 (which is the first byte of the prime).
I don't know why people has never reported this. Maybe they are using Java at both sides, or maybe their other side also trim the zeroes, or, maybe they are just (un)lucky enough that generated secret always starts with a non-zero byte.
Although this looks like a bug, there's a risk fixing it. If "fixed" and unfixed versions of JRE running across a network use the algorithm, there will be a probability (> 1/256) that negotiation would fail.