Zero-knowledge is one of the most abused terms in security marketing. Companies apply it liberally to anything with a padlock icon. In cryptography, "zero-knowledge" has a precise meaning. Understanding that meaning is the only way to evaluate whether a service actually provides the property it claims.
The Formal Definition
In theoretical computer science, a zero-knowledge proof is a protocol where one party (the prover) can convince another party (the verifier) that a statement is true, without revealing any information beyond the fact that the statement is true. Applied to cloud storage and communication, the "zero-knowledge" property means the service provider learns nothing about the content being stored.
For Wispr specifically, the property is: given any interaction with Wispr's infrastructure, an adversary controlling all server resources gains zero information about the plaintext content of any secret. You can read more about the practical implications on our about page.
The Encryption Pipeline
Here is the complete cryptographic pipeline for a message secret, from creation to reveal:
Step 1: Key Generation
The Web Crypto API generates a cryptographically random 256-bit key. The randomness source is the operating system's CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), which on modern systems reads from hardware entropy sources including CPU timing jitter, interrupt timing, and dedicated hardware random number generators.
Step 2: Encryption
AES-GCM requires a 96-bit Initialization Vector (IV). The IV is randomly generated for each encryption operation and stored alongside the ciphertext. It need not be secret — its purpose is to ensure that encrypting the same plaintext twice produces different ciphertexts (semantic security).
Step 3: Key Embedding
The raw key bytes (32 bytes = 256 bits) are base64url-encoded and appended to the URL after the # fragment separator. The HTTP specification (RFC 7230) defines that the fragment identifier is not sent by the client to the server when following a link. It is purely client-side context. The server sees only the secret ID path — never the key portion.
Step 4: Server Storage
The server receives only the ciphertext and IV. There is no plaintext. There is no key. There is no metadata about content type or length (only the encrypted payload size). The server is a blind storage facility.
Password Protection: Key Wrapping
When a password is provided, the system uses AES-Key-Wrap (AES-KW) to encrypt the content key:
PBKDF2 with 100,000 SHA-256 iterations derives a wrapping key from the password and a random salt. The content key is wrapped (encrypted) with this wrapping key. Only the wrapped key bytes, IV, and salt are stored on the server — never the password, never the derived wrapping key, never the raw content key.
To decrypt, the recipient enters the password, PBKDF2 rederives the wrapping key, unwraps the content key, and decrypts the ciphertext. The server is not involved in any step of this process.
What Zero-Knowledge Means in Practice
With this architecture: - We cannot read your secrets. Not as a policy. Not unless compelled. Not under subpoena. We physically cannot because we lack the key. - A server breach exposes nothing. An attacker who exfiltrates the entire database gets encrypted blobs. Without the keys (which live in URLs you control), they have randomness. - Key logging is the only viable attack. If an attacker can modify the client-side JavaScript Wispr serves, they could intercept keys before encryption. This is mitigated by our Content Security Policy and HTTPS with HSTS preloading.
