Security Model

Zero Knowledge

Zephr uses a zero-knowledge architecture. The server stores only ciphertext it cannot decrypt.

Encryption and decryption happen on sender and recipient devices. The sender encrypts locally and sends only ciphertext to the Zephr server. Zephr stores the ciphertext and issues a one-time link. The recipient fetches the ciphertext and decrypts it locally. The encryption key is never transmitted to the server. These properties are enforced by design, not by policy or access controls.

Data Confidentiality

Encryption runs entirely in the sender's client before any data leaves the device. The client generates a fresh random 256-bit key for each secret and encrypts the plaintext using AES-GCM-256. Each secret uses an independently generated key. Compromise of one key exposes nothing about any other secret. Only the resulting ciphertext and initialization vector (IV) are transmitted to the server. The key never leaves the sender's device.

In standard mode, the key is encoded in the URL fragment. As defined in RFC 3986 §3.5, fragment identifiers are not included in HTTP requests to origin servers. The server receives only the request path, never the fragment. In split mode, the sender delivers the key through a channel of their choosing, outside Zephr. Either way, the server stores only ciphertext it cannot decrypt. HTTPS is enforced for all connections with HSTS, preventing downgrade attacks. These are structural properties of the protocol, not configurable server behaviors.

Data Integrity

AES-GCM-256 authentication tags are computed at encryption and verified during decryption on the recipient's device. Any modification to the ciphertext, whether in transit or at rest on the server, causes decryption to fail completely with no partial output. The plaintext either arrives intact or not at all. There is no mechanism to produce a valid plaintext from a tampered ciphertext.

Access Control

Access to each secret is one-time and atomic. The server marks a record consumed on the first successful retrieval. Concurrent requests for the same identifier cannot both succeed. Only one retrieval is possible. After consumption, subsequent requests return 410 Gone immediately.

Secret identifiers carry 128 bits of entropy, making stored records resistant to enumeration. A Content Security Policy restricts script execution to same-origin sources, preventing injected scripts from reading decrypted output in the browser.

Data Lifecycle

Zephr marks each record consumed atomically on the first successful retrieval, making it inaccessible immediately. Subsequent requests for the same identifier return 410 Gone. Records not retrieved before their expiration window elapses are made inaccessible at expiry. Consumed and expired records are permanently purged on a rolling schedule with no backup and no administrative recovery path.

Zephr logs request metadata only: timestamp, HTTP status code, and anonymized IP address. Plaintext, encryption keys, and URL fragments are never written to any log.

Threat Model

Server compromise. An attacker with full access to Zephr's infrastructure obtains only ciphertext under random identifiers. The encryption keys were never stored on the server. The plaintext cannot be recovered from the ciphertext. AES-GCM-256 with 256-bit random keys provides no viable attack surface for brute force.

Network interception. HTTPS with HSTS prevents downgrade attacks. In standard mode, the key travels in the URL fragment, which is not included in HTTP requests to the server. In split mode, the sender delivers the key through a channel of their choosing, outside Zephr. Either way, the key never reaches the server.

Ciphertext tampering. AES-GCM authentication tags detect any modification to the stored ciphertext. A tampered ciphertext fails decryption entirely on the recipient's device.

Device compromise. Zephr protects ciphertext at rest and in transit. It cannot protect plaintext on a compromised device or process. A compromised operating system, an intercepting browser extension, a keylogger, or physical observation can expose plaintext before encryption or after decryption. In agent pipelines, a compromised process or container has the same exposure boundary. No cryptographic protocol protects against a compromised execution environment. These are explicit boundaries of the zero-knowledge model, not gaps to be filled.

Explicit Design Boundaries

Zephr protects ciphertext from the moment it reaches the server until retrieval. Before encryption on the sender's device and after decryption on the recipient's device, the plaintext exists in the client's process memory. Those moments are outside Zephr's scope.

Access is controlled by possession of the link. The link is the credential. The server grants retrieval to whoever presents a valid identifier. It has no knowledge of who the intended recipient is, by design. Adding recipient authentication would require the server to become an identity authority, which would break the zero-knowledge model. The link is the access control. Treat it like a password.

Operational Guidance

Keep your operating system and browser up to date. Unpatched vulnerabilities are the most common attack vector at the device level. Enable full-disk encryption (FileVault, BitLocker, or LUKS) to protect data at rest if your device is lost or stolen. Review your browser extensions and remove any you do not actively use. Extensions run with broad access to page content and can read decrypted output. For sensitive operations, use a private browsing window to limit session persistence.

Zephr links contain decryption keys. Treat them as credentials. A link is effectively the credential itself. Do not share links through channels that generate automatic previews or pre-fetch URLs. Many messaging apps and email clients automatically pre-fetch links, which can trigger retrieval before the intended recipient opens it. In automated pipelines, do not log links or pass them through shared state. Links carry decryption keys. For high-value secrets, use split mode: send the retrieval URL through one channel and the key through another. Use the shortest expiration window your workflow allows. Confirm receipt before the link expires. Once expired, it cannot be recovered.

Once decrypted, the plaintext exists in the recipient's device memory. Zephr writes no decrypted content to disk. Browser caching, memory swapping, and crash recovery are outside Zephr's control and may persist content beyond the application's lifecycle. The recipient is responsible for the plaintext from that point. Do not screenshot decrypted secrets. Screenshots sync to cloud photo libraries and device backups, defeating the one-time design.

When Not to Use Zephr

Do not use Zephr on public or potentially compromised devices. If the device is untrusted, the decryption step is exposed. Do not use it for long-term storage. Secrets expire and cannot be recovered. Each secret can only be retrieved once. If multiple agents or services need the same credential, create a separate secret for each recipient. If your use case requires audit trails, access logs, or key recovery, Zephr is the wrong tool. It is designed to leave no plaintext record of what was shared.