A technical explanation of how SealedKeys protects your secrets. We believe in transparency over security-by-obscurity.
Designed by an AWS Certified Solutions Architect (Professional) — infrastructure, data residency and security boundaries are deliberate architectural decisions, not defaults.
SealedKeys's servers never receive, store, or can compute your plaintext secrets. Every secret is encrypted on your device before being sent. Even if our database were stolen in its entirety, the attacker would have only ciphertext — mathematically useless without your master password.
That means independent security researchers can read the exact code that protects your secrets — not just our description of it. If we've made a mistake, anyone can find it. If we haven't, you don't have to take our word for it.
Your master password is combined with your email address and passed through PBKDF2-SHA256 with 600,000 iterations. This produces your vault key — a 256-bit AES key. This computation happens entirely in your browser using the Web Crypto API.
vaultKey = PBKDF2(masterPassword, email + "sealedkeys_v1", 600000, SHA-256, AES-256-GCM)Each secret's sensitive fields are serialised to JSON and encrypted using AES-256-GCM with a random 12-byte IV (nonce). The output is iv + ciphertext, base64url-encoded.
encryptedData = base64url(iv[12] || AES-GCM(vaultKey, JSON(secretFields)))Only the encrypted blob, the item name (for search), the URL (for favicon matching), and metadata tags. The server can never reconstruct the secret — it lacks the vault key.
Server stores: { name, url, tags, encryptedData } — no plaintext secretsWhen you open your vault, the encrypted blobs are fetched from the server. Your browser derives the vault key again from your master password and decrypts each item locally.
secrets = JSON.parse(AES-GCM-decrypt(vaultKey, base64url-decode(encryptedData)))Your master password is hashed server-side using bcrypt (cost factor 12) solely to verify your identity at login. This hash cannot be reversed to derive your vault key — they are cryptographically independent.
Known limitation
The master password is transmitted over HTTPS for bcrypt verification. A future release will adopt SRP (Secure Remote Password Protocol) to eliminate server involvement in the authentication credential entirely.
✓ What we store
✗ What we never store
You should never be held hostage to any single service. SealedKeys is designed so your data remains accessible regardless of what happens to us.
Export your entire vault as an encrypted JSON file at any time — one click, no support tickets. Format: sealedkeys-encrypted-v1, using the same AES-256-GCM scheme described above. The structure is documented and open — not proprietary.
A self-contained HTML file with zero external dependencies. Enter your master password locally — no internet, no account, no SealedKeys.com required. Works in any modern browser, indefinitely.
Download offline viewer →Commitment: If SealedKeys shuts down for any reason, we will publish the full encryption specification and offline viewer source code publicly before the service ends — ensuring your data remains decryptable with open-source tools, forever.
SealedKeys implements ML-KEM-768 hybrid encryption (NIST FIPS 203) alongside AES-256-GCM. This protects against harvest-now-decrypt-later attacks: adversaries who steal encrypted vault data today — as happened in the LastPass 2022 breach — cannot decrypt it even when quantum computers arrive.
The hybrid scheme means both components must be broken simultaneously. AES-256-GCM provides 128-bit quantum security (Grover's algorithm halves effective key length). ML-KEM-768 provides NIST Level 3 quantum resistance against Shor's algorithm. Neither LastPass nor Bitwarden has implemented post-quantum vault encryption.
How ML-KEM-768 hybrid encryption works →SealedKeys is a web app, not a browser extension. Decrypted secret values are held in page memory while your vault is unlocked. Browser extensions (1Password, Bitwarden) run in a separate OS process and are isolated from page scripts by the browser — a level of memory protection a web app cannot match.
· The vault key itself is non-extractable (extractable: false via Web Crypto API) — raw key bytes never exist in JS heap.
· Decrypted item values are what an XSS could reach. Our nonce-based CSP is the primary defence against XSS.
· A native browser extension is on the roadmap and would close this gap entirely.
Completed items are marked; remaining items are planned for upcoming releases.
The encryption implementation lives in lib/crypto.ts and uses only the browser's built-in window.crypto.subtle API — no third-party cryptography dependencies.

Certified under the UK Government's Cyber Essentials scheme, independently verified against the NCSC's baseline security standard — covering boundary firewalls, secure configuration, access control, malware protection, and patch management.
Verify certificate →A full manual penetration test against the production application was completed in May 2026 — 42 test cases across authentication, session security, IDOR, broken access control, input validation, injection, and transport security. Zero exploitable findings.
Related pages
From the same team
ClearWarden — AI governance platform for customer support teams →Free to start — no credit card. Your secrets stay encrypted on your device — we never see them.