Zero-Knowledge Architecture: A Technical Deep-Dive

Zero-knowledge architecture is a system design pattern where the service provider cannot access user data. Not by policy — by mathematical impossibility. This deep-dive explores the technical patterns that make zero-knowledge work, with a focus on web applications.

Defining Zero-Knowledge

A system is zero-knowledge when:

1. Data is encrypted before leaving the client
2. The server never possesses the decryption key
3. The server stores only ciphertext it cannot decrypt
4. Decryption happens exclusively on the client

This is distinct from "encrypted at rest" (where the server holds the key) or "encrypted in transit" (HTTPS, which terminates at the server).

The Key Distribution Problem

The fundamental challenge of zero-knowledge is key distribution: how does the decryption key reach the recipient without passing through the server?

Solution 1: URL Fragments

The approach used by Only Once Share and other secret sharing tools. The key is placed after the # in the URL:

https://ooshare.io/s/abc123#decryption-key-here

URL fragments are defined in RFC 3986 as client-only — browsers never include them in HTTP requests, server logs, or analytics. This makes them an ideal channel for key transmission.

Pros: Simple, standards-based, no server involvement
Cons: Key visible in browser history, can be screenshotted

Solution 2: Password-Based Key Derivation

Used by many encrypted note and file storage services. The user provides a password, and PBKDF2 or Argon2 derives the encryption key:

key = PBKDF2(password, salt, iterations, keyLength)

Pros: Key never transmitted anywhere
Cons: User must remember and communicate the password separately

Solution 3: Public Key Cryptography

Used by PGP/GPG-based systems. The sender encrypts with the recipient's public key; only the recipient's private key can decrypt.

Pros: No shared secret needed
Cons: Requires PKI, key management complexity

Threat Model

A proper zero-knowledge architecture must consider these threats:

Threat: Compromised Server

Mitigation: Server only stores encrypted data. Without keys (which never touch the server), the data is worthless to an attacker.

Threat: Compromised Server Code (Supply Chain)

Mitigation: Open source allows auditing. Subresource integrity (SRI) can verify that the JavaScript served to clients hasn't been tampered with. Reproducible builds allow verification that deployed code matches the source.

Threat: Malicious JavaScript

Since the server serves the JavaScript that performs encryption, a compromised server could serve malicious code that exfiltrates keys. This is the most discussed weakness of web-based zero-knowledge systems.

Mitigation: Open source + code review, SRI tags, browser extensions that verify code integrity, self-hosting.

Threat: Browser Extensions

Malicious browser extensions have full access to page content, including decrypted data and URL fragments.

Mitigation: User education, extension auditing, using dedicated/incognito browser profiles for sensitive operations.

Implementation Patterns

Pattern: HKDF-Based Per-Message Keys

Don't reuse the master key directly. Derive unique keys per message using HKDF with a context value (like the message ID):

derivedKey = HKDF(masterKey, salt, info=messageId)

This ensures: (1) each message has an independent key, (2) compromising one key doesn't compromise others, (3) the message ID is cryptographically bound to the key.

Pattern: AAD Binding

Use Additional Authenticated Data (AAD) to bind metadata to the ciphertext:

ciphertext = AES-GCM-Encrypt(key, iv, plaintext, aad=messageId)

This prevents ciphertext substitution attacks where an attacker swaps the encrypted payload between different messages.

Pattern: Versioned Ciphertext Format

Prefix ciphertext with a version byte to allow future algorithm upgrades without breaking compatibility:

[version: 1 byte][iv: 12 bytes][ciphertext + tag: variable]

Testing Zero-Knowledge Claims

To verify a system is truly zero-knowledge:

1. Open browser DevTools → Network tab
2. Create a secret with known plaintext
3. Inspect every request body for any trace of your plaintext
4. Inspect the request URL (path and query params) for any key material
5. Verify the URL fragment is present in the browser but absent from network requests

Conclusion

Zero-knowledge architecture provides the strongest privacy guarantee for web applications: mathematical certainty that the server cannot access user data. The URL fragment pattern enables simple, standards-based key distribution for secret sharing tools. Combined with HKDF key derivation, AAD binding, and open source code, it creates a robust foundation for privacy-first applications.