Security model

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.

Core principle: zero-knowledge

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.

Our encryption is open source.

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.

View source →

Encryption flow

1

Key derivation (client-only)

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)
2

Encryption (client-only)

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)))
3

What the server receives

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 secrets
4

Decryption (client-only)

When 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)))

Authentication

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 vs. what we don't

✓ What we store

  • ·Your email address
  • ·bcrypt(masterPassword) — for auth only
  • ·Item names and URLs — unencrypted, for search
  • ·Tags — unencrypted metadata
  • ·AES-256-GCM ciphertext of all secret values
  • ·Audit event metadata (timestamps, actions)

✗ What we never store

  • ·Your master password in plaintext
  • ·Your vault key (derived client-side only)
  • ·Passwords, API keys, SSH keys in plaintext
  • ·TOTP seeds in plaintext
  • ·Recovery codes in plaintext
  • ·Any secret value in any readable form

Data portability & sovereignty

You should never be held hostage to any single service. SealedKeys is designed so your data remains accessible regardless of what happens to us.

Encrypted export

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.

Offline viewer

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.

Post-quantum encryption — NIST FIPS 203

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 →

Known security limitations

Item names and URLs are stored unencrypted (for search). If this is a concern, use generic names.
SRP is not yet implemented — master password is transmitted over HTTPS for bcrypt verification. A future release will eliminate server involvement in authentication entirely.

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.

Security roadmap

Completed items are marked; remaining items are planned for upcoming releases.

TOTP MFA — all accounts
Nonce-based Content Security Policy
Independent security audit (May 2026)
Key versioning (re-encrypt on password change)
SRP protocol (no password traversal)
Passkeys / WebAuthn support
Hardware key (FIDO2) MFA
Per-org encryption keys
Argon2id key derivation upgrade
Breach monitoring (HIBP integration)
End-to-end encrypted export/import
Browser extension (process-isolated memory)

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.

Audit the encryption implementation on GitHub

Certifications & testing

Cyber Essentials Certified

Cyber Essentials Certified

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 →

OWASP web-application security assessment

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.

42
tests run
0
exploitable findings
4
issues fixed pre-test
Download full report (PDF) →

Seen enough to trust it?

Free to start — no credit card. Your secrets stay encrypted on your device — we never see them.