How the Encryption Works

Your passphrase is not the encryption key. It first passes through PBKDF2, the password-based key derivation function specified in RFC 8018 and described for this use in NIST SP 800-132. The function mixes the passphrase with a random salt 100,000 times; the final digest becomes the AES key. The salt is generated fresh for every operation and stored next to the ciphertext. It is not secret. In the Web Crypto API, this is one call: crypto.subtle.deriveKey with hash, salt, and iteration count.

Only two variables set the cost of a brute-force attack: how many guesses an attacker can afford and how expensive each guess is. A high iteration count makes every guess costlier, while a long, unpredictable passphrase shrinks the number of guesses worth trying. Together they push an exhaustive search far beyond what a realistic attacker can finance, while a short everyday phrase with the same iteration count stays cheap to test. Raising the count slows every guess, but a weak passphrase stays weak.

AES-256-GCM, defined in NIST SP 800-38D, does two jobs. It encrypts with a 256-bit key, and it appends a 128-bit authentication tag computed over the ciphertext and any associated data left in the clear. Decryption recomputes and compares the tag. If a single bit anywhere in the ciphertext was changed — by a storage fault, a corrupted download, or deliberate tampering — the comparison fails. Decryption then returns an error instead of plausible-looking garbage.

GCM also imposes a strict rule: a nonce must never repeat under the same key. If it does, relationships between two messages become visible, and the authentication key itself can be exposed. So a fresh random nonce is used for every operation instead of a counter you might reset. Authentication is not a signature, though. It proves that the ciphertext was created with your key. It says nothing about who sent it to you.

Encryption transforms data; it does not duplicate it. If the only copy of the ciphertext is deleted, overwritten, or lost with a drive, no passphrase recovers it. If the key is missing, the encrypted bytes are mathematically worthless. There is no recovery path, no reset link, and no override, because the server holds nothing but ciphertext. Treat ciphertext and key as two separate assets, each needing its own copy.

The endpoint is the other weak point. Malware, a tampered browser extension, or a screen that someone else can read defeats encryption entirely, because the plaintext exists on the device before and after the cryptographic step. Metadata adds a further limit: file names, sizes, timestamps, and storage durations usually stay readable even when content does not. Plan for those gaps before you depend on encryption alone.