Zero-knowledge sharing for the data that matters most.
CircleKey is a TypeScript library that end-to-end encrypts the data your users share with each other — and CircleKey Cloud is the backend to run it on. Keys are created on the device and stay there. Our servers hold ciphertext they have no way to open. It is the thinking behind Signal, reframed for the documents, credentials and records a team works on together.
The problem
Most “end-to-end encrypted” apps keep a copy of the key.
Encrypting one user’s data is easy. The moment two people share something, you own a key-management problem: who holds the key, what happens when somebody joins, and what happens the hour after somebody is removed.
The usual answer is to keep the key on the server and gate access with a permission flag. That quietly turns “end-to-end encrypted” into “encrypted, and also we can read it” — and it means a database leak, a rogue administrator or a court order reaches straight through to the plaintext.
The honest alternative is months of specialist cryptographic work that most product teams cannot justify. So it doesn’t get built. CircleKey is that work, already done, behind an API that looks like the storage API you were going to write anyway.
What it is
A group vault your server cannot open.
A group vault is a shared space with its own keys, its own member list, and its own tamper-evident record of who was let in and who was removed. Your app calls a handful of methods. All the cryptography happens in the browser tab.
Keys are born on the device.
Every device generates its own keypair. Private keys never leave it and are never transmitted to any server — ours included. There is no key escrow, no “recovery copy” held on your infrastructure, and nothing for us to hand over.
Adding or removing someone re-keys the vault.
Every membership change produces a brand-new vault key, sealed individually to each remaining member’s devices. Remove someone and they are locked out of everything written from that moment on — not because a flag says so, but because they do not have the key.
Every device checks the history itself.
Membership is a signed chain: each change references the one before it. A device accepts a change only if it links correctly and was signed by somebody who already held the authority to make it. A compromised, hostile or subpoenaed server cannot forge a membership change, rewrite the past, or slip in an extra reader — every client rejects it at once.
What your users get
Each of these is a normative requirement of the GroupVault Protocol, not a configuration option somebody can forget to switch on. The chips link to the clause.
Your server can’t read it. Neither can we.
Plaintext, vault keys and private keys never leave the device. What reaches storage is ciphertext plus the bookkeeping needed to route it. §5.1
Remove someone and they’re out immediately.
Revocation is a re-key, not a flag. They receive no copy of the new key, so everything written afterwards is unreadable to them. §9.3
Nobody can quietly change who’s in the vault.
Membership changes are signed and chained. Tampering, reordering and rollback are all detected independently by every client. §9.1
Phones, laptops, tablets — all covered.
Users link the devices they actually work on, and revoke a lost one on their own, without an administrator and without disturbing anybody else. §9.5
A lost device isn’t lost data.
Recovery is set up before the first vault opens, never bolted on afterwards. The library structurally refuses to proceed without it — there is no “skip for now”. §9.6
New members get the whole history.
Somebody who joins in month nine can read back to day one, the way joining a shared drive works — without anybody re-uploading or re-encrypting a thing. §9.7
Ten lines to an encrypted vault.
transport is your backend: CircleKey Cloud, or your own server
against the documented interface. Everything else runs on the device.
import { GroupVault } from "circlekey";
// Opens (or restores) this user's identity on this device.
const vault = await GroupVault.open({ transport, userId: "alice" });
// Recovery is mandatory before any vault can be used. Show this
// credential to the user once — no server ever sees it.
const recoveryCredential = await vault.enrollBackup();
// Create a vault. The creator becomes its first manager.
await vault.createGroup("case-4417", { min_managers: 2 });
// Add a colleague, then write something only the two of you can read.
await vault.addMember("case-4417", { userId: "bob", devicePubkey });
await vault.putJsonRecord("case-4417", "note-1", { body: "…" });
// Bob leaves the matter. The vault re-keys; he keeps nothing new.
await vault.removeMember("case-4417", "bob");Who it’s for
Built for the teams who actually need this.
CircleKey is designed for the ten or twenty people who genuinely need access to something sensitive — and it is deliberately efficient at that size, because every membership change re-keys the vault for everybody in it. It is not built for broadcasting a secret to a hundred people. That isn’t a secret.
Health & clinical
A care team around one patient. Records that must not be readable by the vendor hosting them.
Legal
A matter, its documents, and the handful of people on it. Add counsel, remove them at close.
Finance & boards
Deal rooms, board packs, cap tables. Membership that changes and has to be provably auditable.
Journalism
Source material shared by a desk, where “our provider was compelled to hand it over” is not survivable.
HR & investigations
Casework a small panel can see and the rest of the company — and the IT department — cannot.
Security operations
Incident channels, credentials, response notes. Especially when the incident is your own infrastructure.
Straight answers
What our servers can and cannot see.
“The server knows nothing” is a claim we could not defend, so we don’t make it. Here is the split, field by field. If something you consider sensitive shows up on the left — a filename, a title, a label — put it inside the encrypted record, where it belongs.
◐ Visible to us, in plaintext
- The vault’s identifier and its version counter
- What kind of change happened — a join, a removal, a role change
- The member list: user identifiers, device public keys, and who the managers are
- The vault’s governance policy
- Which device signed each change, and its signature
- Record identifiers, sizes and timestamps — so, how much data and how often
- The salt and parameters attached to a recovery backup
● Never received by us at all
- Any plaintext your users write, of any kind
- Any vault key, present or historical
- Any per-record encryption key
- Any device private key
- Any user’s recovery credential
- The contents of a sealed key envelope
- Anything that would let us decrypt, forge or join
CircleKey Cloud
You write the app. We’ll hold the ciphertext.
The library is front-end only. Something still has to store the encrypted records and keep each vault’s history in order — a small service, but a real one to operate. So we operate it. From $5 a month, with a 14-day free trial.
And if you would rather run it yourself, the interface is documented, and there is an executable acceptance test you can point at your own implementation. Both doors are open on purpose — a backend you can leave is the only kind worth trusting.
Ship encryption you don’t have to apologise for.
The library is source-available and Apache-2.0 licensed, so your security team can read every line before you commit to it. The protocol underneath it is public. Nothing here depends on trusting us.