Code Review Request for 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful

Wang Weijun weijun.wang at oracle.com
Tue Jun 25 23:34:21 UTC 2013



在 Jun 26, 2013,6:51 AM,"Valerie (Yu-Ching) Peng" <valerie.peng at oracle.com> 写道:

> It's covered by SQE interoperability tests.

That's enough.

> In terms of regression tests, I think we should not put any 3rd party provider-related stuff.
> I can add a regression test to make sure that optional component doesn't affect the equals check if you see value in doing this kind of test.

That part looks trivial. Not necessary.

Thanks
Max

> Thanks,
> Valerie
> 
> On 06/24/13 21:20, Weijun Wang wrote:
>> Code change looks fine. No regression test?
>> 
>> --Max
>> 
>> On 6/20/13 4:45 AM, Valerie (Yu-Ching) Peng wrote:
>>> I have updated the webrev to address your comments:
>>> http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/
>>> 
>>> As for using JDK 8 default method feature, I think maybe it's better to
>>> delay the adoption to a later release since it's easier for sustaining
>>> to just grab current changes and apply to earlier releases.
>>> Thanks for the review & please let me know if you have additional comments,
>>> Valerie
>>> 
>>> On 06/17/13 22:41, Wang Weijun wrote:
>>>>> I will also apply the same change to P11DHPrivateKey/P11DHPublicKey
>>>>> then. Equality check using ASN.1 encoding is fine for non-DH
>>>>> algorithms but not for DH.
>>>> I cannot read the source codes now, but is it possible to implement
>>>> the equals method right in the base interface using the JDK 8 default
>>>> method feature?
>>>> 
>>>>>> For DHKeyPairGenerator.java, it looks like you don't want the first
>>>>>> octet being zero. Is this related to this bug? Is that required in
>>>>>> the "Handbook of Applied Cryptography" book? I understand it could
>>>>>> be necessary for interop.
>>>>> The change is for conforming to the description under section 7.1
>>>>> "Private-value generation" of PKCS#3 DH Key Agreement Standard
>>>>> ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc , i.e.
>>>>> 
>>>>> An integer x, the private value, shall be generated
>>>>> privately and randomly. This integer shall satisfy 0<   x<
>>>>> p-1, unless the central authority specifies a private-value
>>>>> length l, in which case the integer shall satisfy 2^(l-1)<=
>>>>> x<   2^l.
>>>> Great. I think you can add a reference to pkcs3. The current wording
>>>> seems to say it's suggested by the Handbook.
>>>> 
>>>> Thanks
>>>> Max
> 



More information about the security-dev mailing list