JDK-6259663 : Better handle leading 0x00 bytes in DH secrets
- Type: Bug
- Component: security-libs
- Sub-Component: javax.crypto:pkcs11
- Affected Version: 6
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2005-04-21
- Updated: 2011-07-14
- Resolved: 2005-05-27
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.
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.
| Other | JDK 6 |
|---|---|
| 5.0u4Fixed | 6 betaFixed  |
Description
Some controversy has erupted around the correct formatting of secrets derived using CKM_DH_PKCS_DERIVE in the wake of 4926742. If the MSB is be 0x00 in the derived secret (as will be the case in 1 out of 256 uses), should the leading 0x00 byte(s) be dropped and a short secret be returned? Or should the length of the secret always match the length of the DH modulus? PKCS#11 (and other crypto) specs are not totally clear, but often imply "always full length." However, most implementations behave differently: NSS softtoken, Solaris softtoken in S10 FCS, SunJCE. SSL/TLS also requires "short" secrets if a DH key exchange is used. Regardless, SunPKCS11 should be flexible and tolerate either behavior from a PKCS#11 token. ###@###.### 2005-04-21 20:53:47 GMT
Comments
|