2

In the WebCrypto/Subtle crypto API, you can generate keys and whatnot. However there appears to be a distinct lack of .destroyKey() or something of the sort.

Are keys cleaned up upon their reference count reaching zero or something of the sort? Is there no way to explicitly destroy/remove a key from memory?

Note that my concern isn't one of security as I know this wouldn't give much of a security benefit, though I am worried about resource leaks and the like. It feels weird not being able to clean up after one's self explicitly.

Qix - MONICA WAS MISTREATED
  • 14,451
  • 16
  • 82
  • 145
  • Why do you feel a need to "clean up" or "destroy" keys? What are you trying to accomplish? (You say it isn't about security - what is it about, then?) – meriton May 12 '21 at 00:20
  • @meriton not leaking resources. We're generating quite a few keys, so I'm curious as to when - if ever - keys are cleaned up. – Qix - MONICA WAS MISTREATED May 12 '21 at 00:34
  • AFAIK JavaScript handles garbage collection for memory, so no need to worry about "leaking" memory or anything -- it should all be cleaned up for you, nothing explicit required. – Nisala May 12 '21 at 01:34
  • @Nisala that isn't what I asked though. I'm aware of how garbage collection works in JavaScript, but I wanted to know what happens in the case of WebCrypto. Not all resources are inherently freed the same, as the accepted answer indicates. – Qix - MONICA WAS MISTREATED May 12 '21 at 06:55

1 Answers1

4

The Web Cryptography Specification writes:

Authors should be aware that this specification places no normative requirements on implementations as to how the underlying cryptographic key material is stored. The only requirement is that key material is not exposed to script, except through the use of the exportKey and wrapKey operations.

This specification places no normative requirements on how implementations handle key material once all references to it go away. That is, conforming user agents are not required to zeroize key material, and it may still be accessible on device storage or device memory, even after all references to the CryptoKey have gone away.

That is, a user agent may chose to discard the key data as soon as its CryptoKey becomes eligible for garbage collection, but may also choose to keep the data around longer, for instance until the entire browsing context is discarded upon navigating to a different page or closing the browser tab.

In practice, the difference is unlikely to matter: You can fit thousands if not millions of keys in the memory of any web-capable device, so exhausting memory due to delayed collection of key material is exceedingly unlikely. And since browser implementers have an incentive to keep memory usage low, most will choose to free key material upon collection of the CryptoKey.

meriton
  • 68,356
  • 14
  • 108
  • 175