End-to-end encrypted cloud sync

TL;DR: CookieVault encrypted cookie sync uses Web Crypto API’s AES-256-GCM with PBKDF2-SHA-256-derived keys. Your cookies are encrypted on the device before leaving the browser, and the sync server stores only opaque ciphertext — ciphertext that even CookieVault engineers cannot decrypt. It is a Pro, zero-knowledge feature.

End-to-end encrypted cookie sync is a zero-knowledge mechanism that keeps your cookies in lockstep across devices while ensuring the cloud server stores nothing but undecryptable ciphertext. Your passphrase derives the encryption key on your own device using PBKDF2-SHA-256; that key never touches CookieVault infrastructure, which means neither our engineers, a server compromise, nor a legal demand can reveal your cookies. It is the Pro-tier backbone shared by both CookieVault Editor and CookieVault Guardian, and the cryptographic boundary is open source so the claim is verifiable rather than promised.

How the encryption works

In short: Your passphrase is processed on-device with PBKDF2-SHA-256 (600,000 iterations) to produce a master key. Each cookie record is encrypted with AES-256-GCM through the Web Crypto API before leaving the browser.

The pipeline uses standard, reviewed primitives rather than custom cryptography. PBKDF2-SHA-256 runs for 600,000 iterations to raise the cost of offline passphrase guessing. AES-256-GCM provides authenticated encryption with a fresh 96-bit IV for every record through the browser-native Web Crypto API.

Six properties define the design:

• Client-side key derivation — PBKDF2-SHA-256 turns your passphrase into a key on your device; the key is never transmitted or stored server-side
• Per-record encryption — each cookie is individually sealed with AES-256-GCM, so a single corrupted blob never poisons the whole vault
• Authenticated ciphertext — the AES-GCM authentication tag detects tampering, so a modified blob is rejected rather than silently decrypted into garbage
• Per-device subkeys — each browser derives a fast-unlock subkey so it does not re-run the full PBKDF2-SHA-256 cost on every sync cycle
• Ciphertext-only storage — the sync server persists opaque blobs plus minimal routing metadata, never plaintext
• Open cryptographic boundary — the derivation, encryption, and sync-client code are public so the data path is auditable

A widely held principle in applied cryptography is that you should encrypt before you upload, not trust the server to encrypt for you. That is exactly the boundary CookieVault enforces: the browser is the only place plaintext ever exists.

The threat model

In short: We assume the server can be fully compromised and design so that it does not matter. Server breach, network interception, and a subpoena all reduce to “attacker has ciphertext.” The one scenario that exposes plaintext is an attacker controlling your unlocked device — which no sync system can defend against.

Cookies are bearer tokens: whoever holds a valid session cookie is, to the destination site, you. Browser documentation is explicit that cookies carry session identifiers and authentication state¹, which is precisely why syncing them in plaintext to any third party would be reckless. The threat model treats that seriously.

The honest boundary is the last row: end-to-end encryption protects data in transit and at rest on the server, not an attacker who is already sitting at your unlocked browser. For that you rely on device login, full-disk encryption, and screen locks — defenses that live below the extension.

Free vs Pro

In short: All local cookie work is free forever. Encrypted cross-device sync is the Pro feature ($3.99/month or $29/year) because it is the only capability that needs server infrastructure. The crypto protecting your data is identical regardless of tier.

Pro is only worth paying for if you use more than one device and want them to stay in sync, or if you want the safety net of cookie-history undo. A single-device, local-only user gets the entire core workflow for free. See the pricing page for the full Free / Pro / Team breakdown.

How to set up encrypted sync

1. Install CookieVault (Editor, Guardian, or both) from the download page
2. Open the extension popup and click “Enable sync”
3. Create a Pro account with your email — this only handles billing and routing, never your key
4. Choose a strong passphrase and store it in a password manager; this is the only thing that can ever decrypt your data
5. Confirm the on-device key derivation runs (the popup shows “deriving key…” while PBKDF2-SHA-256 works)
6. Wait for the first encrypted snapshot to upload — all selected cookies are sealed before transmission
7. Install CookieVault on a second device and enter the same passphrase to derive the same key locally
8. Verify the sync indicator turns green on both devices; changed records now replicate as encrypted blobs

If you ever change the passphrase, every device re-derives a new key and re-encrypts its local vault before the next push. There is no server-side re-encryption because the server has no key to use.

Audit and verifiability

In short: The encryption code is open source and reproducible-built, so the data path is verifiable today. An independent third-party audit of the crypto stack is scheduled for Q3 2026, with the report and any findings published in full.

Trust-me security is not security. Because the derivation, encryption, and sync-client code live in public MIT-licensed repositories, anyone can confirm that the key never leaves the device and that only ciphertext reaches the server. Chrome’s extension model further constrains what an extension can touch², and cookies are read and written through the official browser cookie API¹ rather than any private channel. The planned external audit is meant to add a second, independent set of eyes; we will link the report from the security page when it lands.

See also

• CookieVault Editor — the cookie editor that uses this sync engine
• CookieVault Guardian — the auto-delete extension that shares the same Pro sync
• Security — the full E2E encryption design and threat model
• Open source — MIT license, public crypto boundary, reproducible builds
• Multi-account profiles — encrypted profile snapshots that sync the same way
• Pricing — Free / Pro / Team breakdown