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 :  
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.