> RFC 2631 has not be crystal clear on this I am afraid,
and
> NIST SP800-56A (appendix C.1) make it clear
Thanks, Mike/Valerie
For the record, I wasn't disagreeing with the approach or the need to do
this, just pointing out that RFC 2631 wasn't authoritative on the matter
for the RAW operation's data representation. As mentioned, 800-56A:C1
is a better reference/justification.
Brad
On 3/1/2012 2:08 PM, Michael StJohns wrote:
Hi Brad -
The output of the DH calculation needs to preserve leading zeros.
The RFC unfortunately doesn't specify the Integer to Byte conversion primitive,
but both X9.42 and the equivalent text in NIST SP800-56A (appendix C.1) make it
clear that the conversion from Integer to Byte string ends up with a Byte string
of length N where N is the smallest integer where 8^N>= the number of bits of
the prime field.
Those "RAW" bytes are the input into the KDF functions and have to exactly match to get a key
output value that matches. (E.g. hash of "00 01 02 03" is different than the hash of "01 02
03" even though both represent the exact same integer).
In any event, the RFC isn't controlling - the RFC is a profile of the actual
standard X9.42.
Mike
At 02:00 AM 3/1/2012, Brad Wetmore wrote:
On 2/21/2012 5:33 PM, Valerie (Yu-Ching) Peng wrote:
Brad,
Can you please review the fixes for the following 2 bugs:
* 7146728: Inconsistent length for the generated secret using DH key
agreement impl from SunJCE and PKCS11
o http://cr.openjdk.java.net/~valeriep/7146728/webrev.00/
This impacts both SunJCE provider and SunPKCS11 provider. The
implementations are inconsistent within SunJCE provider itself
between the engineGenerateSecret() and
engineGenerateSecret(byte[], int). Given that RFC 2631 specifies
the leading 0s must be preserved so the generated secret has as
many octets as the prime P,
Just to be clear here, you're referring to Section 2.1.2 of 2631, which is just one of the DH Key
agreement variants (based on X9.42) for generating Keying Material from secret keys obtained from a
"raw" DH calculations, and is then subject later SHA1 manipulations, right? This method
provides motivation/incentive to output our secret keys with the same lengths, but I don't think
this RFC makes any claims that the general output of "raw" DH key agreement operation
must be the same length.
I'll take another look over the code tomorrow.
Thanks,
Brad
I have changed both SunJCE and
SunPKCS11 provider to do so. When testing against Solaris and
NSS libraries, Solaris preserves the leading 0s while NSS trims
it off, thus similar handling is also needed in SunPKCS11 provider.
* 7130959: Tweak 7058133 fix for JDK 8 (javah makefile changes)
o http://cr.openjdk.java.net/~valeriep/7130959/webrev.00/
Instead of using the -Xbootclasspath, switching over to use
-boothclasspath for consistency with the backported changes in
the update releases for earlier JDK, e.g. 7u.
Thanks,
Valerie
