Security Architecture

Security Architecture

This page describes Zefer's cryptographic design, the key-derivation chain, and the threat model. All cryptography uses the browser's native Web Crypto API (crypto.subtle); Zefer ships no custom crypto primitives.

Primitives

Purpose	Primitive	Parameters
Symmetric encryption	AES-256-GCM	256-bit key, 12-byte IV, 16-byte tag
Key derivation	PBKDF2-SHA256	32-byte salt, 300k / 600k / 1,000,000 iterations
Secret-question answer	PBKDF2-SHA256	hashed at 100,000 iterations
Randomness	crypto.getRandomValues	salts, IVs, generated keys
Compression (optional)	Gzip / Deflate	via CompressionStream, before encryption

AES-GCM is an authenticated cipher: it provides confidentiality and integrity. Any modification to the ciphertext (or associated data) causes decryption to fail, so tampering is detected automatically.

Key-derivation chain

passphrase
  └─(if dual)─► combine(passphrase, secondPassphrase) via the separator \x00ZEFER_DUAL\x00
       └─► PBKDF2-SHA256(combined, salt[32 bytes], iterations) ─► 256-bit AES key
            └─► AES-256-GCM(key, iv[12 bytes], payload) ─► ciphertext (+16-byte tag)

• Salt is 32 random bytes generated per file; it makes precomputation/rainbow-table attacks infeasible and ensures the same passphrase yields different keys across files.
• Iterations default to 600,000 and can be set to 300k, 600k, or 1,000,000 (mapped from the standard / high / maximum security levels). Higher iterations increase brute-force cost linearly.
• IV is 12 random bytes. For chunked encryption, each chunk uses a unique IV derived from the base IV XOR the chunk index (unsigned 32-bit), so no (key, IV) pair is ever reused.

Chunked encryption

Payloads are encrypted in 16 MB chunks. Each chunk is independently sealed with AES-256-GCM under the same key but a distinct IV, and a 16-byte tag is appended (the Web Crypto API output layout). Benefits:

• Constant, bounded memory use — large files do not have to fit in one buffer.
• Per-chunk integrity — corruption or tampering is localized and detected.
• Streaming-friendly framing — each chunk is length-prefixed (see Binary File Format).

What is and isn't encrypted

Visible without passphrase (public header)	Sealed inside the AES-256-GCM payload
PBKDF2 iterations	Decrypted content (text or file bytes)
Compression method	File name, MIME type, size
Content mode (text/file)	createdAt / expiresAt timestamps
Optional hint and note (you choose to include them)	Hashed secret-question answer + the question
Salt and base IV (public by design)	Allowed-IP allowlist
Reveal-key presence (ZEFR3)	Max-attempts limit

Putting expiration, IP rules, the secret question, and attempt limits inside the ciphertext means they cannot be read or edited by anyone without the passphrase, and GCM authentication guarantees they were not altered.

Dual passphrase (two-person rule)

When dual mode is enabled, two passphrases are concatenated with a fixed separator (\x00ZEFER_DUAL\x00) before key derivation. Both are required to derive the key; neither alone is sufficient. This supports two-person authorization workflows.

Reveal key

A reveal key lets you share a file so the recipient can open it without ever seeing the main passphrase. The file is stored in the ZEFR3 format with two independently encrypted blocks (a main block and a reveal block). See Security Features and Binary File Format.

Threat model

Protected against

• Server compromise / data breach — there is no server storing your data; nothing is uploaded.
• Passive interception — a .zefer file is ciphertext; intercepting it reveals only the public header.
• Tampering — GCM authentication detects any modification.
• Offline brute force — mitigated by 256-bit keys and high-iteration PBKDF2; strength depends on passphrase entropy (use the Password Generator and Analyzer).
• Metadata snooping — security metadata is encrypted, not in the public header.

Not a substitute for

• A weak passphrase. All security ultimately rests on passphrase entropy. Generate strong keys.
• Endpoint security. If the device running the browser is compromised (malware, keylogger), no client-side tool can help.
• Access controls as cryptographic guarantees. IP allowlists and max-attempts are enforced by the client at decryption time; they raise the bar but are policy checks, not cryptography. The content is always protected by AES-256-GCM.
• Post-quantum threats to the asymmetric layer — Zefer is symmetric (AES-256), which retains an effective 128-bit security margin under Grover's algorithm; there is no public-key component to break.

Reporting vulnerabilities

See the project's Security Policy and the /security page on the site for responsible-disclosure guidelines.