Skip to content
ProtectedShare

Cryptography

Why AES-256-GCM Matters for Browser Encryption

Why authenticated encryption matters for secret links, how AES-256-GCM is used in the browser, and the details that matter more than key length.

By Updated
First published 2 min read

Key length is the least interesting part

AES-256 is the label people remember, but a 256-bit key is rarely what fails. What matters is the mode of operation, how the key is derived, and whether random values are used correctly. AES-256-GCM is popular because the mode does two jobs at once.

Confidentiality plus integrity

GCM is an authenticated mode. NIST's specification, SP 800-38D, describes it as an algorithm for "authenticated encryption with associated data." Every ciphertext carries a 16-byte authentication tag, and decryption checks it. If a single byte of the ciphertext, the IV or the associated data has changed, decryption fails outright instead of returning altered text. MDN's Web Crypto documentation strongly recommends authenticated encryption for exactly this reason.

For a secret-sharing tool that matters: a tampered note should refuse to open, not open with someone else's edits.

How it's used in the browser

Browsers ship AES-GCM in the Web Crypto API, so there's no need for a hand-written cipher in JavaScript. In ProtectedShare's current scheme:

  • A fresh 12-byte random IV for every encryption. GCM's security depends on never reusing an IV with the same key; MDN's AesGcmParams page puts it plainly: never reuse an IV with the same key.
  • Keys derived with HKDF. The AES key comes from HKDF-SHA256 (RFC 5869) over either 32 random bytes carried in the link, a password stretched with PBKDF2-SHA256 at 600,000 iterations, or both. 600,000 is the iteration count the OWASP Password Storage Cheat Sheet recommends for PBKDF2-HMAC-SHA256.
  • The sharing mode is bound in as associated data, so a note sealed to require both the link key and a password can't be relabelled to skip the password.
  • File chunks carry their position. In a file drop, each chunk is encrypted separately with its index and the total count as associated data, so chunks can't be reordered, swapped or dropped without decryption failing.
  • Keys are non-extractable CryptoKeys, so page scripts can use them but can't read the raw key material back out.

What AES-256-GCM can't fix

  • Weak passwords. When the key comes from a password, the cipher is only as strong as the password. Stretching makes each guess expensive; it doesn't make "summer2026" safe. Use the random link key, or a long password from a password generator.
  • Size leaks. GCM doesn't pad, so the ciphertext is the length of the plaintext plus the tag. A server can tell a short password from a long .env file.
  • Key handling. Whoever has the key can decrypt. Where the key travels, and who can see it on the way, matters more than which cipher protects the data.

The exact construction, including what the server stores, is on the security page.

Sources

Comparevs Privnotevs OneTimeSecretvs EnvSharevs ProtectedTextvs Bitwarden SendAll comparisons