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

Valerie (Yu-Ching) Peng valerie.peng at oracle.com
Tue Jun 25 23:46:36 UTC 2013


Great, thanks for the review!
Valerie

On 06/25/13 16:34, Wang Weijun wrote:
>
> 在 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