Code Review Request for 7146728 and 7130959

[Valerie (Yu-Ching) Peng]

Yes, that's the section that mentioned the generated secret having the 
same length as p.
I guess it depends on how it's interpreted. The way I look at it is that 
if the generated secrets aren't of the same length, then whoever using 
this variant for deriving the keying material will need to do the extra 
work of checking the size of generated secret assuming that they know 
the size of p to add back the leading 0s if needed.
I can't find any specification dictating trimming off the leading 0s for 
the generated secret. Considering both models, preserving vs trimming, I 
feel the former makes more sense since it is simpler to use and provides 
more flexibility than the later. RFC 2631 has not be crystal clear on 
this I am afraid, that's why there has been some inconsistency in 
different vendors implementation since people interpret what they read 
differently.
Valerie

On 02/29/12 23:00, 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
>>
>>