I'm building a personal end-to-end encrypted chat application and have run into a secure-storage paradox. Data in localStorage or IndexedDB is generally available as plaintext on disk, while encrypting a private key before storing it still leaves the decryption key or usable key material exposed to code running in the application. Web Crypto can create non-extractable CryptoKeyPair objects and persist them in IndexedDB, but those keys cannot be exported or wrapped for an additional layer of at-rest encryption. Is there a practical way to store a key so that it is usable only by this browser or device while also being protected at rest? I'm aware that no solution is perfect, but the gap between origin-restricted runtime access and plaintext browser storage seems significant. One idea I've considered is splitting the cryptographic material between a non-exportable Web Crypto key and a passphrase-encrypted key in localStorage, requiring both to decrypt messages, but that feels unnecessarily complicated. Would passkeys, WebAuthn, or another browser API solve this problem, or is this simply a limitation of browser-based cryptography?
2 Answers
Another common design is to use a passkey or other protected credential to derive or release a key-encryption key, then store the encrypted application key as a blob in localStorage, IndexedDB, or on a server. The stored blob is useless without the authenticator or passphrase. However, don't treat an arbitrary private key as a normal password, and don't invent a custom split-key or encryption scheme without carefully reviewing the threat model. Passkeys are generally safer because the private credential remains under browser or operating-system control.
A passkey is probably the closest built-in solution. It uses a public-key credential whose private key is kept by the browser, operating system, or an authenticator, rather than being exposed as ordinary JavaScript data. Your application can request assertions from it without directly exporting the private key. For stronger designs, look at WebAuthn and supported extensions such as PRF for deriving or unlocking application-specific encryption keys. There isn't a general-purpose browser storage API that gives JavaScript both a permanently non-exportable key and arbitrary encrypted-at-rest storage under a separate passphrase.
The part that concerns me is that browser-managed storage may still ultimately be written to an ordinary file on disk. I understand that no cryptographic primitive is broken here; the limitation seems to be the browser storage model and the lack of a hardware- or OS-backed keystore exposed directly to web applications.
That only protects the stored blob if the passkey operation can provide a secret or key-derivation result without exposing the credential itself. A regular WebAuthn signature is not automatically a reusable AES passphrase, so the exact API and authenticator support matter.