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

Weijun Wang weijun.wang at oracle.com
Tue Jun 25 04:20:45 UTC 2013


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