JDK-6977937 : The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE.
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-08-18
  • Updated: 2019-02-11
  • Resolved: 2016-08-17
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 9
9 b133Fixed
Related Reports
Relates :  
JDK-8164307 - sun/security/krb5/auto/EmptyPassword.java failed with IllegalArgumentException: EncryptionKey: Key bytes cannot be null
Relates :  
JDK-6578538 - com.sun.crypto.provider.SunJCE instance leak using KRB5 and LoginContext
Relates :  
JDK-8218723 - Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation
Relates :  
JDK-8164494 - SunPKCS11 requires a non-empty PBE password
Description
This may be too restrictive.  Investigate and fix if appropriate.

We could have fixed this as part of JDK-6578538, but chose to remain with the SunJCE string.
Comments
The PBKDF2KeyImpl class is not Cloneable and its private Mac field is never exposed beyond the class so support for Cloneable is not an issue.
11-08-2016
One possible reason for not specifying a provider + relying on the provider list order is due to the clone support. Especially for the native providers such as OracleUcrypto and PKCS11 provider, the clone support depends on the underlying native library and may not always be there. If the clone capability is used or required, then we need to make sure the particular implementation supports it.
27-07-2016