How It Works

How It Works

End to end, Zefer takes your input, derives a key from your passphrase, encrypts everything (content and security metadata) with AES-256-GCM, and packages it into a portable .zefer file. Decryption reverses the process and enforces any access rules. Nothing touches a server.

The seven steps

1. Input — you provide text or a file, plus a passphrase (minimum 6 characters). Optionally a second passphrase, a reveal key, an expiration, a secret question, an IP allowlist, a max-attempts limit, compression, and a PBKDF2 strength.
2. Key derivation — your passphrase is stretched into a 256-bit AES key with PBKDF2-SHA256 using a fresh random 32-byte salt and the configured iteration count (300k / 600k / 1,000,000). With a dual passphrase, both secrets are combined first (see Security Architecture).
3. Payload assembly — the content is packed together with its metadata (file name/type, createdAt, expiresAt, hashed secret-question answer, allowed IPs, max attempts) into a single buffer: 4-byte metadata length + metadata JSON + raw content bytes.
4. Encryption — the payload is encrypted with AES-256-GCM using a random 12-byte IV. Large payloads are split into 16 MB chunks, each encrypted with a unique IV derived from the base IV. A 16-byte authentication tag is appended to each chunk, which also detects tampering.
5. Packaging — Zefer writes a .zefer binary: a magic header (ZEFB3, or ZEFR3 when a reveal key is present), a small public header (iterations, compression, hint, note, mode), the salt and IV, and the encrypted chunks. See Binary File Format.
6. Download & share — the file is created in memory and downloaded locally. Share it through any channel; it is useless without the passphrase.
7. Decryption — the recipient uploads the file and enters the passphrase. The browser repeats key derivation, verifies the GCM tag, decrypts the payload, and then enforces expiration, IP, secret-question, and attempt limits. Wrong passphrase → failure with no information leak.

Why "everything is encrypted"

A common mistake in "secure link" tools is to keep metadata (like an expiration date) in the clear, where it can be read or edited. Zefer puts all security metadata inside the AES-256-GCM ciphertext. The only thing visible without the passphrase is the small public header (KDF iterations, compression method, content mode, and the optional public hint/note you chose to include). Because GCM is authenticated, any change to the ciphertext is detected on decryption.

Technical specifications

Property	Value
Algorithm	AES-256-GCM (authenticated)
Key derivation	PBKDF2-SHA256
Iterations	300,000 / 600,000 / 1,000,000 (configurable)
Salt	32 bytes (256 bits), random per file
IV	12 bytes (96 bits), random; per-chunk unique
Auth tag	16 bytes per chunk
Key size	256 bits
Chunk size	16 MB
API	Web Crypto API (SubtleCrypto)
Compression	None / Gzip / Deflate (before encryption)
Server involvement	None (100% client-side)

See Security Architecture for the key-derivation chain and threat model, and Security Features for each optional control.