-
Notifications
You must be signed in to change notification settings - Fork 1
Glossary
Plain-language definitions of every term used in this wiki. Each entry gives an everyday explanation first, then a short technical note. You do not need a security background to follow along — start here whenever a word is unfamiliar.
Big picture in one sentence: Zefer turns your secret into a locked box (
.zeferfile) that only your passphrase can open, and it does all the locking and unlocking on your own device.
Plain: The "lock" Zefer uses. It scrambles your data so it looks like random noise, and it also stamps a tamper-proof seal so any change is noticed. Technical: Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode — an authenticated symmetric cipher providing confidentiality and integrity. Hardware-accelerated on most CPUs and used in TLS and government systems.
Plain: Encryption that also detects tampering. If even one byte is changed, unlocking fails instead of returning garbage. Technical: A mode (here, GCM) that produces ciphertext plus an authentication tag; decryption verifies the tag before returning data.
Plain: A 16-byte "wax seal" attached to the locked data. If the seal is broken (data altered), Zefer refuses to open it. Technical: The 128-bit GCM tag; a MAC computed over the ciphertext. Zefer appends one tag per chunk (the Web Crypto API layout).
Plain: A convention for writing multi-byte numbers "most important part first" — like writing 1,234 rather than 4,321. Technical: Byte order in which the most significant byte comes first. Zefer stores all length prefixes big-endian.
Plain: Guessing a passphrase by trying every possibility until one works. Technical: Exhaustive key search. Its cost grows with passphrase entropy and the number of PBKDF2 iterations.
Plain: A 16 MB "slice." Big files are locked slice by slice so your device never has to hold the whole thing at once. Technical: A ≤16 MB segment, each encrypted with AES-256-GCM under a unique IV and its own tag, length-prefixed in the file.
Plain: Plaintext is your readable secret; ciphertext is the scrambled, locked version. Technical: Plaintext is the input to the cipher; ciphertext is the encrypted output (here, plus the GCM tag).
Plain: Everything happens on your device, in your browser. Nothing is sent anywhere. Technical: Computation runs in the browser via JavaScript and the Web Crypto API; no server processing.
Plain: Optionally shrinking your data before locking it, so the file is smaller.
Technical: Gzip/Deflate applied to the payload before encryption, via the CompressionStream API.
Plain: Requiring two passphrases to open a file — like a safe that needs two keys turned together.
Technical: Two secrets combined (separator \x00ZEFER_DUAL\x00) before key derivation; both are required to derive the key.
Plain: How unpredictable a passphrase is. More entropy = harder to guess. Measured in "bits": each extra bit doubles the guessing effort.
Technical: Shannon entropy of the secret, roughly log2(alphabet) × length, adjusted for structural weaknesses.
Plain: A one-way "fingerprint" of data. You can make the fingerprint from the data, but not the data from the fingerprint. Technical: A cryptographic hash producing a fixed 256-bit digest. Used for file fingerprints and (via PBKDF2) the secret-question answer.
Plain: A random "starter value" so that locking the same thing twice never looks identical. Technical: A 12-byte nonce for AES-GCM, random per file; each chunk uses a unique IV (base IV XOR chunk index) so no IV is reused under a key.
Plain: Turning your human passphrase into a proper cryptographic key — deliberately slowly, so guessing is expensive. Technical: Stretching a passphrase into a 256-bit key via PBKDF2 with a salt and many iterations.
Plain: A standard way for AI assistants to use tools. Zefer offers an MCP "server" so an AI agent can encrypt/decrypt for you.
Technical: A JSON-RPC protocol over stdio; zefer mcp exposes tools an MCP client (Claude, Cursor, etc.) can call locally.
Plain: A "key-stretching" recipe that makes deriving the key from your passphrase intentionally slow (hundreds of thousands of steps), so brute-forcing is painful for attackers. Technical: Password-Based Key Derivation Function 2 with HMAC-SHA256; Zefer uses a 32-byte salt and 300k/600k/1,000,000 iterations.
Plain: The bundle that gets locked: your content plus its hidden settings (file name, expiration, etc.).
Technical: 4-byte metadata length + metadata JSON + content bytes, encrypted as one unit inside AES-256-GCM.
Plain: Even a future quantum computer would only halve AES-256's effective strength — leaving it as strong as a 128-bit key, still far beyond reach. Technical: Grover's search gives a quadratic speedup, reducing AES-256's brute-force security margin to ~128 bits. There is no public-key component to break.
Plain: The small, readable label on the outside of the box (which lock settings were used). It contains no secrets.
Technical: Cleartext JSON: iterations, compression, hint, note, mode. Everything sensitive is sealed in the ciphertext.
Plain: A website you can "install" so it behaves like a normal app and works offline. Technical: A web app with a service worker and manifest enabling installation and offline caching.
Plain: A second, shareable password that lets someone open a file without ever learning your main passphrase. Technical: A separate encrypted block in the ZEFR3 format, derived from an independent key.
Plain: A random pinch of data mixed in before key derivation, so the same passphrase produces a different key every time and precomputed attack tables are useless. Technical: 32 random bytes per file, fed into PBKDF2.
Plain: An extra question whose answer is also required to open the file. Only a fingerprint of the answer is stored, never the answer itself. Technical: The answer is hashed with PBKDF2-SHA256 (100,000 iterations); only the hash is stored, inside the payload.
Plain: One secret key used both to lock and unlock. "256-bit" means there are astronomically many possible keys. Technical: A single shared AES key (256 bits = 2²⁵⁶ possibilities) derived from your passphrase.
Plain: A "best before" time after which the file will not open.
Technical: A UTC timestamp (ms) stored inside the payload and checked after decryption (0 = never).
Plain: The browser's built-in, audited toolbox for encryption. Zefer uses it instead of writing its own crypto.
Technical: crypto.subtle — the standard browser interface for AES-GCM, PBKDF2, hashing, and secure randomness.
Plain: Zefer (and its makers) literally cannot see your data or passphrase — there's nothing to see, because nothing is sent anywhere. Technical: An architecture where secrets never leave the client; the service holds no keys, plaintext, or accounts.
Plain: The two file "shapes" Zefer writes: ZEFB3 for a normal single-passphrase file, ZEFR3 when a reveal key is added.
Technical: Binary container formats (magic ZEFB3 / ZEFR3) — see Binary File Format.
📖 Back to: Home · How It Works · Security Architecture
📖 New to a term? See the Glossary. · Zefer · Repository · CLI · MIT © José Carrillo
Guides
- Getting Started
- How It Works
- Examples and Recipes
- Install and Self-Hosting
- Comparisons
- Troubleshooting
- FAQ
Security
Channels
Tools
Project
Reference