Hi Sebastian, Thanks for your interest in the security APIs.
This issue is more complex than it looks on the surface. You have alluded to one of the issues, which is that BigInteger is immutable and thus cannot be easily cleared.
Rather than trying to have a discussion about this now, I would appreciate if we could delay discussion of this topic for a couple of weeks as we are quite busy meeting the RDP1 deadline for JDK 25. Stay tuned for more details.
Thanks, Sean On 5/19/25 6:10 AM, Sebastian Stenzel wrote:
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
