The SecretKey interface was extended to include Destroyable in Java 8 but no implementation was provided for destroy to the concrete SecretKeySpec class.
Comments
[~valeriep] The behaviours that you mention seem reasonable and appropriate. Since what you say is true then perhaps they should be documented in the SecretKey interface? I understand it might be more difficult to change the behaviour of this method implementation but documenting the expected or required behaviour of implementations would seem to be useful. Ambiguity helps nobody.
04-08-2025
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."