Revocation means changing the locks

Every file-sharing product has a button that removes a person from a folder. Click it, their name disappears from the member list, and the job looks done. In most products that is exactly what happened: a row in a permissions table was deleted. The server will now refuse that person’s requests. Nothing else changed.

For a service that holds plaintext, that is enough, because the server is the only way in. For an end-to-end encrypted service it is not, and the reason is worth understanding, because it decides whether “removed” means anything.

Permissions are a promise; keys are a fact

In NomadVault, a person who can read a folder holds the keys to it, sealed to their own key pair, on their own device. The server enforces roles, viewer, editor, co-owner, and it will refuse to hand out ciphertext to someone without a grant. But roles are a policy the server applies. They are not cryptography. Whoever holds a key and can obtain the ciphertext can decrypt it, and the server is not the only place ciphertext exists: it sits in browser caches, in the desktop sync client’s local copy, in a download someone made last week.

So if removing a person only deleted their grant, two things would remain true. Their device would still hold working keys for everything in the folder. And a copy of the ciphertext, obtained before or after, would still open. A compromised server, or a backup of it, could hand that ciphertext over. “Removed” would mean “we will stop helping them”, not “they cannot read it”.

We did not want a member list that lies. So revocation in NomadVault rotates keys: when someone is removed, the locks they had keys to are replaced.

What happens when you remove someone from a folder

Every folder in NomadVault has its own key pair, and every file key inside it is sealed to that pair. Sharing a folder hands the recipient a sealed bundle containing the folder’s private keys, which in turn open the keys of every subfolder and file beneath. One grant, a whole subtree.

Removing a person reverses that at the cryptographic level. In your browser, in a single transaction:

Every folder in the subtree gets a fresh key pair, classical and post-quantum, like all keys in NomadVault.
The encrypted folder names are re-sealed to the new pairs.
Every file key in the subtree is re-sealed to its folder’s new pair. The file keys themselves, and the encrypted files in storage, do not change. Nothing is re-uploaded.
Every remaining member is granted the new bundle at the point where they were originally shared in, with a fresh signature.

The removed person’s bundle now opens keys that nothing uses any more. Any ciphertext they fetch from now on is sealed to pairs they never received. The confirmation you see in the interface says it plainly: “removed, folder keys rotated”.

Because only key material is rewritten, this is fast even for large folders. A subtree with thousands of files re-keys in seconds, and no file content moves.

Removing someone from a single file

A shared file is different, because there is no key hierarchy above it to rotate. The file key is the lock. Re-sealing the same file key to the remaining people would change nothing for the person who already has it.

So single-file revocation goes one step further: your browser decrypts the file, encrypts it again under a new file key, uploads that as the new current version, seals the new key to everyone who should still have access, and the old version and its storage object are destroyed in the same operation. The removed person’s key now opens a ciphertext that no longer exists.

This is heavier than the folder case, since the file travels through your browser once, but it is the only way to make “removed” true for a standalone file.

Removing someone from a group

Groups let you share a folder once with a whole team. The group has its own key pair, and members hold its private keys sealed to themselves. That convenience has a consequence for revocation: a member who opened a shared folder did so through the group’s keys, and may have cached the folder’s own keys along the way. Rotating the group key alone would not touch those.

So when a member leaves, two things happen in one transaction. The group’s key pair is rotated: a new pair is created, sealed to every remaining member, and every grant that was sealed to the group is re-sealed to the new pair. And every folder the group was shared into is re-keyed exactly as in the folder case above: fresh folder key pairs, names and file keys re-sealed, remaining members and the group itself re-granted. The group admin who removes the member does all of this in their browser, because the group bundle gives them the folder keys and the group’s share gives them the standing. The confirmation reads “the group key was rotated and 1 shared folder re-keyed”, with the real count.

The person who left holds keys to a group that no longer exists and to folders whose locks have been changed. Being removed from a group does not touch access they were given personally; a direct share they hold on one of those folders survives the re-key, as it should.

What revocation cannot do

Here is where honesty matters more than the feature list.

It cannot recall copies. If a person downloaded a file while they had access, they have that file. Rotating keys stops them reading anything new and stops them re-fetching what they had; it does not reach into their laptop. The same is true of every system ever built, including paper. Sharing is a decision about who may see something from now on, and revoking is a decision about who may see it from now on, not retroactively.

It cannot un-cache instantly. The desktop sync client keeps a local copy of synced folders. After a revocation the client can no longer fetch anything, but the files it already holds stay until it is told to drop them. Treat the laptop of someone who leaves the way you would anyway: as something to reclaim.

Older versions of a revoked file keep their old key. When a single file is re-encrypted, previous versions in its history still carry the earlier file key. A former recipient who already downloaded one of those versions can still open it. Versions they never fetched are unreachable, since the server no longer serves them anything.

If a key chain is broken, we say so. Re-keying a folder needs its whole key chain intact. When a folder revocation cannot open the chain, the operation falls back to deleting the grant and tells you the keys could not be rotated, instead of reporting a success it did not achieve. When a group removal hits such a folder, that folder is left out, the removal still goes through, and the message says how many folders were skipped so the folder’s owner can re-key them from the member list.

Why this is worth the complexity

A permissions table is simpler to build, and for most products it is all there is. But a design in which the provider cannot read your files has to take its own promise seriously at the edges, and the edges are where people leave. If removing someone did not change the keys, a compromised server plus a departed employee’s laptop would be enough to read a folder forever, and the provider would have no way to know.

Changing the locks when someone leaves is what you would do with a building. We think the same standard applies to documents, and we would rather tell you exactly where the standard stops than let the member list imply more than it delivers.

Questions?

If you want to talk through how revocation fits your offboarding process, or your security team wants the full technical description of the key rotation, get in touch at hello@nomadvault.de.