Skip to content
Skip to content
Get started
/Getting Started

Getting Started

Core concepts

A few ideas explain almost everything about how zcrypt works. Understand these and the rest of the product reads itself.

Your vault

Your vault is your encrypted drive: the entire tree of folders and files that belong to you. It is presented like any normal drive, but every name and every byte inside it is encrypted on your device before it is stored. The server holds only ciphertext and the structure needed to fetch it back.

The passphrase

Your passphrase is the one secret that unlocks the vault. It is not a login credential: your account password handles signing in. Instead, zcrypt feeds the passphrase through a key derivation function in your browser to produce your vault key. That key, and the passphrase behind it, are never transmitted to our servers.

No recovery

Because nothing readable leaves your device, a forgotten passphrase cannot be reset. There is nothing on our side to recover it from. Store it in a password manager. See Passphrase & key management for the derivation details.

Folders

Folders are real and nestable, just like on a desktop drive. Open one and create another inside it, as deep as you like. A folder's name is encrypted on your device exactly like file contents, so your organization is private too. When the vault is locked, names show as placeholders until you unlock.

A folder can also have its own password layered on top. See Per-folder encryption.

Files & per-file keys

zcrypt uses envelope encryption. Each file gets its own random content encryption key (CEK) that encrypts that file's bytes with AES-256-GCM. The CEK itself is then encrypted (“wrapped”) by the key derived from your passphrase.

The payoff: your passphrase only ever has to protect small wrapped keys, not gigabytes of data. To open a file, zcrypt unwraps its CEK with your vault key, then uses the CEK to decrypt the content, all locally.

Chunks

Each file is split into chunks first: pieces sized to your device (4, 8, 10 or 16 MiB; 10 MiB is the usual). Each chunk is then compressed and encrypted on its own. Chunks are what actually get uploaded, one per request, to the repositories or channel on your connected platform. On download, zcrypt fetches the chunks, verifies them, and reassembles the file on your device.

The vault lock

The vault has a single lock state, surfaced as one pill in the interface and unlocked through one modal. Enter your passphrase once and the whole vault unlocks for the rest of the session. There is no per-file or per-folder prompting to wade through.

The unlock lasts for a session time-to-live (TTL). When it expires, the pill returns to locked and the next action that needs your key reopens the single modal.

Staying unlocked on a device

When unlocking, you can choose “keep me unlocked on this device.” Instead of re-typing your passphrase every session, zcrypt stores it encrypted at rest in your browser's IndexedDB, sealed under a non-extractable key the browser will not hand back to any script.

Plain localStoragezcrypt on this device
Stored asReadable textCiphertext in IndexedDB
Sealing keyNoneNon-extractable, browser-held
Sent to servern/aNever

Safer than localStorage, but still local trust

This is meaningfully harder to scrape than a passphrase sitting in localStorage, and it is never sent to the server. It still trusts the device, so only enable it on hardware you control. Locking the vault or signing out clears it.