Safari and CryptoKeys

[sechel]

I have a small piece of code that runs in Chrome and Firefox but not in Safari. It involves CryptoKeys as generated by the WebCrypto API. And these keys seem to be the source of the issue:

const db = new Dexie('TestDB');
db.version(1).stores({test: 'id,IDB_class'});
const key = await window.crypto.subtle.generateKey({name: 'AES-CBC', length: 128}, false, ['encrypt']);
const testData = {id: 1, IDB_class: 'test_class', key};
await db.table('test').put(testData);
const result = await db.table('test').where('IDB_class').equals('test_class').first();

The following observations can be made:

• result is undefined and should really be equivalent to testData
• If I set key to null result is correct
• if I change the query to be const result = await db.table('test').get(1); result is correct.

It seems that the CryptoKey is preventing the query from successfully being executed. However queries involving only the primary key are not affected. Inspecting the corresponding db with the developer tools reveals that the db is in fact there and the CryptoKey is stored as expected. I use Safari Technology Preview 39 and Dexie 2.0.0-rc.1.

Greetings Stefan

[dfahlander]

I thought CryptoKey was not part of the structured clone algorithm, but reading through the WebCrypto API recommendation, it recommends to support it in structured clone algorithm so that it can be stored in IndexedDB. Probably this is new stuff and not fully supported in Safari. I saw this post that looks interesting. What happens if using window.crypto.webkitSubtle.generateKey() instead of window.crypto.subtle.generateKey()?

[sechel]

Hey David, I created a fiddle to test this, there is an implementation using Dexie and one using native IndexedDB. https://fiddle.jshell.net/sechel/qn7oesaf/

In TechPreview of Safari the prefix of the WebCrypto API was removed. Otherwise the behaviour is the same for this example. It doesn't seem to be a Dexie problem though, as the native implementation exhibits the same issue.

We are storing all our keys in IndexedDB, this is especially useful when keys are non-extractable. Then you have persistent keys that cannot be stolen by potentially malicious javascript code.

[dfahlander]

It's a nice feature indeed. Should file issue on webkit Bugzilla if time allows

[sechel]

Done: https://bugs.webkit.org/show_bug.cgi?id=177350

[sechel]

The Webkit team doesn't react at all here. Any ideas how to accelerate this process, this is a blocker for us, and probably for others?

[m90]

@sechel Did you ever find a solution to this? I am hitting the same limitation still today and would also much love to keep my keys non-extractable (I could save them in JWK format just fine, but that'd kind of defeat the purpose).

---

I also found your relatively recent comment here: https://bugs.webkit.org/show_bug.cgi?id=182972, but I am not sure if this is referring to the same approach and if it's even talking about Desktop or Mobile Safari (I am currently working against Desktop)

[sechel]

@m90 No, unfortunately not. All our CryptoKeys are still stored in JWK format on Safari and on iOS. Would really appreciate any movement on the WebKit side on this issue.

[DominicTobias-b1]

2021 Safari still doesn't support much of the Crypto API, the last browser not to do so :(

[sechel]

2021 Safari still doesn't support much of the Crypto API, the last browser not to do so :(

What exactly do you miss? They have improved considerably in the last few years. Unfortunately not in combination with frames or IndexedDB which both have long standing issues.

[sechel]

There is movement on the WebKit side 🎉 https://bugs.webkit.org/show_bug.cgi?id=182972

[httpjamesm]

Any update on this? I'm working on an app that relies heavily on the ability to store CryptoKeys in IndexedDB.

[dfahlander]

CryptoKeys are supported in Safari (https://bugs.webkit.org/show_bug.cgi?id=182972 is resolved)