-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: 6
-
Component/s: security-libs
-
beta
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2125616 | 5.0u4 | Andreas Sterbenz | P3 | Resolved | Fixed | b04 |
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
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
- backported by
-
JDK-2125616 Better handle leading 0x00 bytes in DH secrets
-
- Resolved
-