Hi all, I noticed that most classes implementing javax.security.auth.Destroyable do not actually overwrite it. After discussing this topic with Christian Stein last week, I decided to add some implementations.
First, I’d like to start with trivial cases with keys encapsulating byte[], as done with symmetric keys or Edwards curves. Later, I might move on to other PrivateKeys, that have some BigInteger that can only be mutated via reflection - doing so is probably debatable. Before starting, I’d like to get a better understanding of whether there is a reason why destroy() isn’t used. Instead, I found uses of alternative ways of (eventually) destroying secrets, such as * via jdk.internal.access.SharedSecrets.getJavaSecuritySpecAccess().clearEncodedKeySpec(keySpec); * via jdk.internal.ref.CleanerFactory.cleaner().register(…) Neither exposes a way to let the API consumer erase key data at a deterministic point in time. I am fully aware this doesn’t reliably prohibit memory dumps from containing the keys. Nevertheless I believe such control is desirable as a best effort attempt to keep keys short-lived when possible. Think of ephemeral key pairs for single-shot ECIES, for example. I hope you can either shed some light on the current state or give me the green light for a PR. Best regards, Sebastian
