Code Review Request for 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful
weijun.wang at oracle.com
Wed Jun 12 18:27:01 PDT 2013
Not sure if we really need to fix the equals() method here. Is there a
spec saying the equality is based on internal fields instead of encoded
I am saying this because it's not easy to get equals() correct here. In
DHPrivateKey.java, the new equals() requires the other object to be
instanceof javax.crypto.interfaces.DHPrivateKey. I see that another
class P11DHPrivateKey also implements this interface but has not
overridden equals, so it looks like a
com/sun/crypto/provider/DHPrivateKey could equals() to a
P11DHPrivateKey, but a P11DHPrivateKey will not equals() to a
Same with DHPublicKey.java.
BTW, the hashCode() methods in these 2 classes use <<2 and <<4 which
looks not as cool as the normal "*31+". I would simply use
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.
On 5/29/13 9:25 AM, Valerie (Yu-Ching) Peng wrote:
> Can you help reviewing my fix for 7196805 "DH Key interoperability
> testing between SunJCE and JsafeJCE not successful"?
> In SunJCE provider, the equality check for DH private/public keys is
> based on DER encoding which may not be correct all the time due to the
> optional L value defined in the DER syntax. In addition, JsafeJCE
> provider sometimes encode the optional L value incorrectly which leads
> to unexpected IOException when parsing the DER bytes.
> I have changed the comparison to based on component values rather than
> DER encodings which may vary due to the presence or missing of optional
> values. In addition, I made the changes to DHKeyPairGenerator to ensure
> that generated private value has the requested length/size.
> Webrev: http://cr.openjdk.java.net/~valeriep/7196805/webrev.00/
More information about the security-dev