Hi Sean, I was hoping to have the „trivial“ implementations (pure byte[] wrappers such as SecretKeySpec etc) done before RDP1. I expect the second PR to cause more discussions.
Cheers! Sebastian > On 19. May 2025, at 21:41, Sean Mullan <sean.mul...@oracle.com> wrote: > > 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 >
