JDK-8160206 : SecretKeySpec should implement destroy()
Type:Bug
Component:security-libs
Sub-Component:javax.crypto
Affected Version:8,9
Priority:P3
Status:Open
Resolution:Unresolved
OS:generic
CPU:generic
Submitted:2016-06-23
Updated:2025-06-04
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.
The SecretKey interface was extended to include Destroyable in Java 8 but no implementation was provided for destroy to the concrete SecretKeySpec class.
Comments
Hmm, this would require CSR as overriding the default impl of destroy()/isDestroyed() would change existing behaviors of getEncoded()/destroy()/isDestroyed() and we need to document the new behavior in javadoc. In addition, once a key is destroyed, its serialization should fail.
Note that using a destroyed key with various crypto services using a SecretKey, e.g. SecretKeyFactory, Cipher, would lead to IllegalStateException.
03-06-2025
While at it, I think it would make sense to change the default implementation of destroy() to do nothing. Otherwise the callers would need to catch exceptions when dealing with unknown providers.
25-04-2025
Reopen, as even just clearing the internal buffer is better than doing nothing at all. In addition, this would still be necessary if VM were to add support for clearing all copies of it later. This can help alleviate the caller's burden of trying to clearing the key bytes inside the SecretKeySpec object afterwards.
25-04-2025
[~mduigou] Adam's previous explanation was unintentionally marked Confidential. Here is his explanation:
"Clearing the buffer doesn't fully solve the problem, since the secret could have been copied to other places in memory by the JVM. So we would need support from the JVM to zeroize secrets. If that support is added, then we can revisit issues like this one."