- Home
- Documentation
- Keys: managed or sovereign
Documentation
Keys: managed or sovereign
Who holds the key to your backups, how the five shares work, what the yearly escrow test does and how to restore without Zekura.
Encrypted on your server
Everything the agent sends is encrypted on your server (AES-256-GCM) before it leaves. The storage partner only sees encrypted blocks; Zekura sees metadata (how much, when, which snapshot) but no content. The password of the encrypted repository is derived from a 32-byte customer key, never the other way round.
Two models
When creating a destination you choose who holds that customer key:
| Managed (default) | Sovereign | |
|---|---|---|
| Where the key is generated | in the portal | in your browser, and it never leaves it |
| What Zekura stores | a locked copy plus the fingerprint | only the fingerprint |
| What you get | the key in 5 shares (3 needed), visible under Getting started until you confirm | the key (hex) plus 5 shares, shown once |
| Can Zekura restore if you lose everything | yes | no, never, and you sign for that |
| What you must do on every server | nothing | set the key on every agent, verifier and worker |
| Verification and maintenance | by Zekura's verifiers and workers | only by your own verifiers and workers |
Managed is for those who want peace of mind: you are never locked out. Sovereign is for those who contractually need that nobody outside the organisation can ever decrypt.
The five shares
The shares are pieces of the key according to Shamir's scheme: with any three shares the key can be fully reconstructed, with two you know literally nothing. Keep them in five places: two people, a safe, a password manager, paper. The portal shows them exactly once and asks you to confirm that they are stored. That confirmation goes into the chain; without it you get a warning after a week.
The escrow test
A key you have not tested is a key you do not have. Once a year, or whenever you like via Settings → Storage → escrow test, you enter three shares. Zekura rebuilds the key in memory, compares the fingerprint and discards it. Pass or fail, it goes into the chain. After a year without a test you get a reminder.
Restoring without Zekura
Install the agent on a clean machine, set the key with your three shares (the fingerprint must match), and the agent can connect with the bucket credentials and restore. We do not need to exist for that. That is the intention.
The signatures under the chain
The records in the evidence chain are signed with the platform's Ed25519 key. That key is rotated; every record carries the identifier of the key that signed it, and the export contains all public keys. Old records remain verifiable forever.