JDK-7147618 : KeyAgreement.generateSecret(byte[],int) returns wrong data for DIFFIEHELLMAN
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 1.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2012-02-21
  • Updated: 2012-02-22
  • Resolved: 2012-02-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u4Resolved
Related Reports
Duplicate :  
JDK-7146728 - Inconsistent length for the generated secret using DH key agreement impl from SunJCE and PKCS11
Description
The DIFFIE HELLMAN implementation uses the BigInteger class.
The Conversion of BigInteger to the byte array sometimes adds the 0 byte for 
the sign. And if the sign byte is removed by the  KeyAgreement.generateSecret()
method, the KeyAgreement.generateSecret(byte[],int) does not removes it.
To reproduce the bug, the attached com.oracle.df_test.Test can be used.

The com/sun/crypto/provider/DHKeyAgreement.java uses the following algorithms
to detect the sign byte.
   protected byte[]  [More ...] engineGenerateSecret()
...
        if ((tmpResult.bitLength() % 8) == 0) {

It looks correct

But engineGenerateSecret(byte[] sharedSecret, int offset)
uses other approach

        if ((secret.length << 3) != modulus.bitLength()) {
This approach has two issues
1. It always remove leading byte if the modulus.bitLength() is dividable by 8
2. It does not remove the sign byte in some other cases.