Sharing Without Trust: How Shared-Vault Encryption Actually Works
Sharing usually means trusting a company's servers with your secrets. Kinship Vault's shared vaults do not. Here is the plain-English version of how a vault reaches other people end-to-end encrypted, with no server, ours or Apple's, that can read a thing.
Most "secure sharing" quietly relies on a company you have never met. The data is encrypted, yes, but a server in the middle holds a key, or could, and "we can't read your data" rests on a promise rather than on math. Kinship Vault was built on the opposite principle: zero-knowledge, no server that can read your vault. Adding sharing without breaking that promise took some careful cryptography. Here is how it fits together, without the jargon.
Key takeaways
- Every device has an identity key pair; the private half never leaves the device.
- A shared vault has one content key. To let someone in, that key is sealed to their public key, so only their device can open it.
- Everything stored in the cloud is ciphertext. Apple's iCloud is just an encrypted relay; there is no Kinship server at all.
- The member list is signed by the owner and pinned on first accept, so no one can quietly add themselves or swap the keys.
- Removing a member rotates the content key, so they cannot read anything written after they are out.
The cast: three keys
Only three ideas do the heavy lifting.
| Key | What it is | Where it lives |
|---|---|---|
| Identity key | A key pair per device (a public half to share, a private half to keep). Think of the public half as a padlock anyone can snap shut, and the private half as the only key that opens it. | Private half in the device keychain, this device only, never uploaded |
| Content key | The single key that actually encrypts the vault's logins, notes, and documents. | Never stored in the clouds; only ever stored sealed to a member |
| Signing key | The owner's key for signing "here is who is in this vault," so members can verify it was really the owner. | Private half on the owner's device only |
Letting someone in, step by step
When you invite a person and grant them access, here is what actually happens.
The invitee's device offers its public identity key, the padlock. Its private key stays put.
Your device seals a copy of the vault's content key to the invitee's public key. Under the hood this is ECIES: a fresh one-time key is generated for this seal, combined with their public key through an ECDH handshake and HKDF to derive a wrapping key, and the content key is encrypted with AES-256-GCM. Each seal is bound to that specific recipient and one-time key, so a sealed copy cannot be re-pointed at anyone else.
The result is stored in a small "key ring" the members' devices can fetch. It is useless to anyone without the matching private key, including Apple and including us.
The invitee's device uses its private identity key to unseal the content key, then keeps that key sealed locally to their own hardware, so from then on the shared vault unlocks with their Face ID like any other vault.
The content key travels through the cloud the way a locked box travels through the mail. The courier carries it; the courier cannot open it.
Why the cloud never sees your data
Every record the shared vault syncs, each password, note, and document, is encrypted with the content key before it leaves the device. What lands in Apple's iCloud is an opaque envelope of ciphertext plus some public keys. There is no Kinship Vault server in the path; iCloud is used purely as a dumb, encrypted relay to move envelopes between members. A look at the stored records shows no readable password, note, or title, only ciphertext.
Stopping the sneaky attacks
End-to-end encryption of the contents is necessary but not sufficient. Two subtler questions matter: could someone tamper with the list of members, and could a removed person keep reading?
A signed, pinned member list
The key ring and membership are signed by the owner's signing key. When you accept an invitation, your device pins the owner's signing key on first use, and every later update is checked against that pinned key. If someone swapped the key ring or tried to add themselves, the signature would not match the pinned owner key, and your device refuses it. Membership changes are also owner-restricted: a non-owner cannot produce a signature the others will accept, so their attempt is rejected across everyone's devices.
Revocation that actually revokes
When the owner removes someone, the vault's content key is rotated: a new content key is generated, re-sealed only to the members who remain, and the vault's version is bumped. New records use the new key. The removed person never receives it, so even if they somehow kept cloud access, everything written after their removal is unreadable to them.
The same promise, extended
Nothing here weakens Kinship Vault's core: local-first, on-device encryption, no server that can read your vault. Sharing simply teaches that model how to include other people, by sealing keys to them rather than handing secrets to a company. If you want the practical side, start with the shared vaults announcement; for the foundations, see on-device encryption explained and what the Secure Enclave is.
Cryptography you can explain to your family.
Share a vault end-to-end encrypted, with keys sealed to each person and revocation that truly revokes. No server, ours or anyone's, can read it. On iPhone, iPad, and Mac.
Explore Kinship Vault