Client-Side Encryption —
your browser does all the cryptography

crypto.subtle is implemented in C/C++ by browser vendors (Google, Mozilla, Apple, Microsoft) — the same teams responsible for TLS, HTTPS, and certificate handling. It's compiled native code, not JavaScript. Hardware-accelerated on CPUs with AES-NI instructions for performance orders of magnitude faster than JS libraries.

We have zero third-party crypto dependencies — no CryptoJS, no forge, no tweetnacl, no sjcl. Pure JavaScript crypto implementations are difficult to audit, susceptible to timing attacks, and add supply chain risk. Any npm package in a dependency chain could introduce a backdoor or vulnerability. We use none of them.

The Web Crypto API specification is maintained by the W3C and has been reviewed, criticized, and improved by the cryptographic research community for over a decade. Each browser's implementation is independently security-audited and has been subjected to enormous real-world scrutiny across billions of devices.

Modern CPUs include AES-NI (Advanced Encryption Standard New Instructions) — dedicated silicon for AES operations. The Web Crypto API uses these instructions automatically. AES-256-GCM encryption on a modern laptop runs at multiple gigabytes per second. Your vault operations complete in milliseconds.

Symmetric encryption for all vault data — passwords, notes, files, metadata. GCM mode provides both confidentiality and authenticity in one operation: the authentication tag detects any tampering with the ciphertext. 256-bit key size is considered post-quantum secure against Grover's algorithm. Each item uses a unique random 96-bit IV.

Key derivation from your master password. 600,000 iterations with a 256-bit random salt. PBKDF2 is NIST-approved and OWASP-recommended for password-based key derivation. The iteration count deliberately slows down brute-force attacks while remaining fast enough for interactive login.

Asymmetric encryption for vault sharing. Each user has an RSA-4096 key pair. When sharing a vault, the vault's AES key is encrypted with the recipient's public key. Only the recipient's private key (derived from their master password) can decrypt it. 4096-bit keys provide a wide security margin above the minimum 2048-bit recommendation.

One-way hashing for the auth key sent to the server. SHA-256 is used to hash the derived auth key before transmission — the server stores only this hash for identity verification. Even if the server is compromised and the hash is obtained, it cannot be reversed to recover the auth key or master password.

The Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) for all random values — IVs, salts, key generation, and the password generator. Draws from OS entropy (hardware events, timing noise, CPU thermal noise). Not Math.random(), which is unsuitable for security use.

Data sent to the server is already AES-256-GCM encrypted at the application layer. It's then wrapped again in TLS (HTTPS) at the transport layer. An attacker who could somehow break TLS (they can't) would still face AES-256-GCM ciphertext they cannot decrypt without your encryption key.