Privacy tools

Shared vaults

Beta

Shared vaults (spaces) let a group work on the same set of end-to-end encrypted files. Each space carries its own key, sealed to every member so only members can open its files, and the server only ever holds ciphertext it cannot read.

What shared vaults are

A shared vault, or space, is a vault you own but open up to other zcrypt users. You give it a name (and optionally a description, both sealed under the space key so the server stores them unreadable), invite members by their account email, and add files. Spaces live on their own pages (/spaces, with pages to create one, add files, and change settings), and the lists support keyboard multi-select. Every member can download the space’s files and decrypt them end-to-end, without ever learning your vault passphrase and without the server being able to read anything.

The trick is that a space has its own key: a random 256-bit key generated in your browser when you create the space. That key is what unlocks the space’s files, and it is handed to each member in a form only that member can open. The server stores the sealed grants and the wrapped file keys but can never combine them into anything readable.

What the server can and cannot see

The server holds only opaque ciphertext for a space: the per-member sealed space-key grants, the file keys wrapped under the space key, and members’ public keys and fingerprints. It never sees the space key, any member’s private key, file contents, or any vault passphrase, every unseal, unwrap, and decrypt happens in the browser.

How the encryption works

Three layers of keys make a space work. Understanding them explains exactly why the server can host a shared vault without being able to read it.

1. Your encryption keypair (per user)

Before you can join or run a space, your account needs an X25519 keypair. It’s generated in your browser the first time you unlock your vault. Your private key is wrapped under your passphrase-derived key (PBKDF2 → AES-256-GCM) before it’s stored, so the server only ever holds ciphertext for it. Your public key and a short fingerprint are stored in the clear so others can seal things to you.

2. The space key (per space)

When you create a space, your browser generates a fresh random 256-bit space key. For every member (including you) that key is sealed to their X25519 public key using an ECIES sealed box: an ephemeral X25519 keypair does ECDH with the recipient, the shared secret is hashed into an AES-256-GCM key, and the ephemeral public key rides along so the recipient can reconstruct it. Only the holder of the matching private key can open it, the server cannot, because it never has any private key.

Per-member sealed space-key grant (base64)

ephemeralPublicKey[32]  ||  AES-256-GCM( 12B IV || ciphertext || 16B tag )

An opened space key is cached in memory for the session only. It is never written to disk and is cleared on logout.

3. The file keys (per file)

Each file already has its own content-encryption key (CEK). To share a file into a space, your browser unwraps that CEK with your vault passphrase, then re-wraps it under the space key and uploads only the opaque envelope. Any member downloads the file by unwrapping that envelope with the space key, no owner passphrase involved. The file’s chunks in storage never change; only a new wrapped copy of its key is added.

Roles

Every member holds one of three roles:

Role	Capability
Viewer	Download and decrypt the space’s files.
Editor	Download, plus add files (ones they own) and remove files from the space.
Admin	Everything an editor can do, plus invite and remove members, change roles, and edit the space's name and description. Only the owner can grant the admin role or change or remove another admin.

New members default to viewer unless you choose otherwise. Some actions are reserved for the owner regardless of anyone’s role: re-keying the space, deleting it, and granting or changing the admin role. Any member can also leave a space on their own.

Adding a file requires owning it

You can only share a file you own, because sharing it means unwrapping its key with your own vault passphrase before re-wrapping it under the space key. Editors and admins can add files they own and remove any file from the space; viewers can only download.

Inviting & verifying members

•Invite by email: the account must already exist on zcrypt and have set up its encryption key (the person needs to have signed in and unlocked their vault at least once). If they haven’t, the invite is rejected until they do, because there’s no public key to seal the space key to.
•Pick a role when inviting: viewer, editor, or admin (only the owner can invite someone as admin). Re-inviting an existing member updates their role and re-issues their key grant.
•Remove a member at any time as the owner or an admin (only the owner can remove an admin). Removal flags the space for a re-key; see below.
•Delete the space as the owner. The underlying files stay in each owner’s vault; only the sharing is torn down.

Verify fingerprints out of band

Each member is shown with the fingerprint of their public key, the first 16 hex characters of its SHA-256, grouped like A1B2-C3D4-E5F6-7890. Your browser computes each fingerprint itself from the member’s key, pins it the first time you see it (trust on first use), and asks you to confirm if the key ever changes. Compare that against the fingerprint the member sees in their own encryption-key settings, over a channel the server doesn’t control (in person, a call, a signed message). Matching fingerprints rule out a server that tried to swap in its own key to eavesdrop. If a member hasn’t published a key yet, no fingerprint is shown and you can’t grant them access.

Sharing & downloading files

•Add files (owner, editor, admin). Pick files or whole folders from your vault. Each one’s key is re-wrapped under the space key in your browser; the server stores only the re-wrapped envelope. Files are added in the background with a progress strip, in batches. On the free plan one add carries at most 200 files by default (the instance operator can change the cap).
•Download (any member): the space key unwraps the file’s envelope and the chunks are decrypted locally. Access is authorised through your membership without ever loosening the owner’s file scoping; an unauthorised request is indistinguishable from a plain not-found.
•Remove files (editor, admin): unshares the file from the space. The original file is untouched in the owner’s vault.

A space can carry an optional size limit, set when you create it. It caps the total original size of the files shared into the space and is enforced on the server when a file is added: adds that would exceed the cap are rejected. Re-adds during a re-key don’t count twice, so rotation never trips the limit. Leave it blank for no limit.

Removing members & re-keying

Removing a member has to be more than deleting a database row, that member may have already opened the space key in their browser. So removal triggers a re-key: your browser generates a brand-new space key, seals it to every remaining member, and re-wraps every shared file’s key under the new key. The removed member gets no new grant, and because every file now answers to a new key, any copy of the old key they kept is useless going forward. This is what makes removal a true revocation, not just a hidden button.

•Automatic on removal: when the owner removes someone, the re-key runs right after. If it doesn’t complete (for example, the space wasn’t unlocked), you’re told to finish it with the manual Re-key. When an admin removes someone, the space is flagged as needing a re-key and adding files pauses until the owner runs it.
•Manual Re-key: the owner can rotate the space key at any time from the members panel, to rotate periodically or to complete an interrupted revocation.
•Owner-gated: only the owner can re-key. A re-key hands out fresh grants to everyone, so it’s deliberately kept out of non-owner hands.

Anti-lockout: all-or-nothing rotation

A re-key is applied atomically and must supply a fresh grant for every current member. The server rejects a partial rotation, so files can never be moved onto a new key while a member is left stranded on the old one. Re-keying needs the space to be unlocked, since your browser uses the old key to re-wrap the files under the new one.

Revocation is forward-looking

Rotating the key stops a removed member from opening the space’s files from that point on. Like any sharing system, it can’t recall data they already downloaded: plaintext that has left the space is beyond its reach.

Maturity

Shared vaults are in beta

End-to-end sharing works today: sealed per-member key grants, file-key re-wrapping, fingerprint verification, and revocation-by-rotation all ship. It’s marked beta because the workflows and surfaces around it are still evolving. Every member needs their encryption keypair set up before they can be granted access, and sharing or re-keying requires the relevant vault or space to be unlocked in your session.