It's covered by SQE interoperability tests.
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.
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
