Interop with IndexedDB

[sgryt]

Hi there,

Firstly, thank you for taking the time to creating this library! It really does make a lot of headaches go away :)

I have a question about using it in conjunction with IndexedDB (testing done in IE11), which seems not to be able to store the underlying Key instances (the _key field in the custom CryptoKey definition). That makes for a problem when reading back the stored keys from IndexedDB, as the connection to the original Key instance is lost along the way, and the keys can no longer be used with the Web Crypto API.

Can you say anything about if it would be possible to support this? I would be more than happy to work on a PR for this, but I'm a bit at a loss for where to start.

Best, Mikkel

PS: I've tried (naively) to change the definition of the _key property on the custom CryptoKey prototype to be enumerable:

_key: {
  value: key,
  enumerable: true
},

, which fixes my issue, but I'm not sure if doing so would break anything else. The test suite still passes (in Chrome) after this change, but as that part of the code is not executed in Chrome, I'm not sure about any possible ramifications.

[Ruffio]

@sgryt is this still an issue? @vibornoff can the suggested change be implemented?

[vibornoff]

@Ruffio it's still an issue. My CryptoKey wrapper doesn't integrate seamlessly with IndexedDB. The way @sgryt makes IDB work with CK-wrapper isn't error-proof for all use-cases:

• when CK instance is stored into IDB, ctructured clone is performed, so IDB record actually contains not a WebCrypto Key, but the object like defined here;
• when the record is retrieved, it should be inflated back to CK instance, but IDB API doesn't provide any way to seamlessly patch retrieved data before it would be handled by an application;
• moreover it makes stored records fragile for browser upgrade (once the shim is turned off on newer version of browser, keys can't be read from IDB without additional migration step);
• but if it's possible to hook on structured clone somehow and store the underlying key object instead of CK wrapper object, some attributes of the key would be lost.

Dead end.

[Ruffio]

@vibornoff what do you think?