How Zero-Knowledge Encryption Actually Works (with the Web Crypto API)

The threat model

Assume the server is hostile, or will be subpoenaed, or will be breached. A note-taking app that "encrypts at rest" and promises not to peek doesn't survive this model - the operator holds the keys. Zero-knowledge flips it: the key never exists on the server in the first place.

Deriving a key from a password (PBKDF2)

Passwords are low-entropy, so you never use them directly as keys. You stretch them with a slow KDF. A production-safe configuration in 2026:

• Algorithm: PBKDF2 with SHA-256
• Iterations: 100,000 (raises brute-force cost)
• Salt: 128-bit random per note (defeats rainbow tables)

async function deriveKey(password, salt) {
  const enc = new TextEncoder();
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    enc.encode(password),
    "PBKDF2",
    false,
    ["deriveKey"]
  );
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: 100000, hash: "SHA-256" },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

Encrypting with AES-256-GCM

GCM is authenticated encryption: it gives you confidentiality and tamper-detection in one primitive. Generate a fresh 96-bit IV for every encryption so identical plaintext never yields identical ciphertext.

async function encryptNote(plaintext, password) {
  const salt = crypto.getRandomValues(new Uint8Array(16)); // 128-bit
  const iv = crypto.getRandomValues(new Uint8Array(12));   // 96-bit
  const key = await deriveKey(password, salt);
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    key,
    new TextEncoder().encode(plaintext)
  );
  // Only these three values leave the browser:
  return { salt, iv, ciphertext };
}

The critical line is the last comment. The server receives salt, iv, and ciphertext - three values that are indistinguishable from random bytes without the password. There is no plaintext to leak, subpoena, or sell.

Why this is the only honest form of "private notes"

If a service can read your notes, then "we don't" is a policy that can change with an acquisition, a court order, or a breach. If a service architecturally cannot read your notes, the guarantee holds even when the company doesn't. That's the whole point of a zero-knowledge architecture: compromise of the server yields ciphertext, not content.

Persistent vs. ephemeral

There are two families here. Ephemeral tools (think one-time secret links) destroy the note after a single read - great for handing someone a password once. Persistent zero-knowledge notepads keep the encrypted blob at a stable URL so you can come back to it across devices. They're complementary, not competitors.

I've been using SecureText, a free encrypted notepad, as my persistent scratchpad because it implements exactly the flow above - AES-256-GCM, PBKDF2-SHA-256 at 100k iterations, Web Crypto only - and adds developer-friendly touches like multi-tab notes and custom URL slugs instead of random IDs. No account, no tracking, and you can inspect the client-side crypto in your own dev tools.

Takeaways

• Never use a password as a key - stretch it with PBKDF2 (or Argon2).
• Use authenticated encryption (AES-GCM), fresh IV every time.
• If plaintext or keys touch the server, it isn't zero-knowledge.
• Audit the client. Open dev tools and confirm what actually gets sent.

If you're building anything that stores user text, run the network tab and ask one question: can the server read this? If yes, your users are trusting you, not math.