Saving Web Crypto Keys using indexedDB

README.md

This is a working example on how to store CryptoKeys locally in your browser. We are able to save the objects, without serializing them. This means we can keep them not exportable (which might be more secure?? not sure what attack vectors this prevents).

To try out this example, first make sure you are in a browser that has support for async...await and indexedDB (latest chrome canary with chrome://flags "Enable Experimental Javascript" works). Load some page and copy and paste this code into the console. Then call encryptDataSaveKey(). This will create a private/public key pair and encrypted some random data with the private key. Then save both of them. Now reload the page, copy in the code, and run loadKeyDecryptData(). It will load the keys and encrypted data and decrypt it. You should see the same data logged both times.

test.js

async function encryptDataSaveKey() {
	var data = await makeData();
	console.log("generated data", data);
	var keys = await makeKeys()
	var encrypted = await encrypt(data, keys);
	callOnStore(function (store) {
		store.put({id: 1, keys: keys, encrypted: encrypted});
	})
}

function loadKeyDecryptData() {
	callOnStore(function (store) {
    var getData = store.get(1);
    getData.onsuccess = async function() {
    	var keys = getData.result.keys;
      var encrypted = getData.result.encrypted;
			var data = await decrypt(encrypted, keys);
			console.log("decrypted data", data);
	   };
	})
}

function callOnStore(fn_) {

	// This works on all devices/browsers, and uses IndexedDBShim as a final fallback 
	var indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB || window.shimIndexedDB;

	// Open (or create) the database
	var open = indexedDB.open("MyDatabase", 1);

	// Create the schema
	open.onupgradeneeded = function() {
	    var db = open.result;
	    var store = db.createObjectStore("MyObjectStore", {keyPath: "id"});
	};


	open.onsuccess = function() {
	    // Start a new transaction
	    var db = open.result;
	    var tx = db.transaction("MyObjectStore", "readwrite");
	    var store = tx.objectStore("MyObjectStore");

	    fn_(store)


	    // Close the db when the transaction is done
	    tx.oncomplete = function() {
	        db.close();
	    };
	}
}

async function encryptDecrypt() {
	var data = await makeData();
	console.log("generated data", data);
	var keys = await makeKeys()
	var encrypted = await encrypt(data, keys);
	console.log("encrypted", encrypted);
	var finalData = await decrypt(encrypted, keys);
	console.log("decrypted data", data);
}





function makeData() {
	return window.crypto.getRandomValues(new Uint8Array(16))
}

function makeKeys() {
	return window.crypto.subtle.generateKey(
    {
        name: "RSA-OAEP",
        modulusLength: 2048, //can be 1024, 2048, or 4096
        publicExponent: new Uint8Array([0x01, 0x00, 0x01]),
        hash: {name: "SHA-256"}, //can be "SHA-1", "SHA-256", "SHA-384", or "SHA-512"
    },
    false, //whether the key is extractable (i.e. can be used in exportKey)
    ["encrypt", "decrypt"] //must be ["encrypt", "decrypt"] or ["wrapKey", "unwrapKey"]
   )
}

function encrypt(data, keys) {
	return window.crypto.subtle.encrypt(
    {
        name: "RSA-OAEP",
        //label: Uint8Array([...]) //optional
    },
    keys.publicKey, //from generateKey or importKey above
    data //ArrayBuffer of data you want to encrypt
)
}


async function decrypt(data, keys) {
	return new Uint8Array(await window.crypto.subtle.decrypt(
	    {
	        name: "RSA-OAEP",
	        //label: Uint8Array([...]) //optional
	    },
	    keys.privateKey, //from generateKey or importKey above
	    data //ArrayBuffer of the data
	));
}

@themikefuller thanks buddy.

So basically there's no windows certificate store equivalent inside WebCrypto api.
This example saves the encryption key and the data inside the same object inside Indexdb.
Indexdb apparently already had wrong implementations where different browser profiles had access to the same index db, meaning anyone could read and use the data inside it, rendering this unsafe.
The only safe way I've found so far was to use AES encryption and have the user enter a password used to encrypt/decrypt data.
Frustrating because from what people were commenting online one gets the impression there's a way to store those keys in an unexportable way, when there only thing the exportable flag is actually "used" is when you import a key and try to export it into one of the formats, but there's no real built in way where the key is stored securely in a store and can only be used for encryption/decryption/signing WITHOUT the possibility to actually get your hands on the key with javascript.

These days you may consider webauthn with an extension such as prf or largeBlob. At least it isn’t cleared like IndexedDB could be, and can be used to securely store keys that are unlocked by the user. You can generate challenges on a blockchain and therefore smart contracts can trust that the user authorized. An interesting security model. Another model can be to have immutable pages. But the real key in all this is guaranteeing that a website (HTML and all resources it references with SRI) match a hash. Then it can be proven not to do malicious things. Otherwise JS can use the keys non-interactively to sign anything, or send them to a server. Sincerely, Greg Magarshak Qbix Inc.

…

On Wed, Jan 8, 2025 at 9:27 AM Luka ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ So basically there's no windows certificate store equivalent inside WebCrypto api. This example saves the encryption key and the data inside the same object inside Indexdb. Indexdb apparently already had wrong implementations where different browser profiles had access to the same index db, meaning anyone could read and use the data inside it, rendering this unsafe. The only safe way I've found so far was to use AES encryption and have the user enter a password used to encrypt/decrypt data. Frustrating because from what people were commenting online one gets the impression there's a way to store those keys in an unexportable way, when there only thing the exportable flag is actually "used" is when you import a key and try to export it into one of the formats, but there's no real built in way where the key is stored securely in a store and can only be used for encryption/decryption/signing WITHOUT the possibility to actually get your hands on the key with javascript. — Reply to this email directly, view it on GitHub <https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5#gistcomment-5379065> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACV7P7Z67V43KD3LFRYPC32JUYUPBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVA2DCMBWGYYTMMVHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .