Zero-knowledge backup: who holds the key to your data?

"Encrypted" is not one thing

Almost every backup service says your data is encrypted. The question is: where does that happen, and who holds the key?

Model	Where it is encrypted	Who can read
Encryption at rest at the provider	on the provider's servers	the provider, and anyone who takes over its systems or serves it an order
Encryption in transit	on the way (TLS)	the provider, as soon as it arrives
Zero knowledge (end-to-end)	on your server, before sending	only whoever holds the key, and that is you

Only the third model means that a data breach at the storage provider, a court order in another country or a curious employee cannot touch you: what is stored there is mush.

How it works at Zekura

The agent on your server encrypts everything with AES-256-GCM before it leaves. The password of the encrypted repository is derived from a 32-byte customer key. The storage partner only sees encrypted blocks. Zekura sees metadata: how much, when, which snapshot, whether verification passed. Not the content. The homepage shows the difference literally: your side, our side.

Managed or sovereign: the choice you have to make

Zero knowledge has a flip side: whoever loses the key loses everything. That is why there are two models:

Managed (default). The key is generated in the portal. You get it in five shares, three of which you need. Zekura keeps a locked copy so that you are never locked out, and can only use it to restore for you if you have lost everything. That is the model for most organisations: the risk of losing the key outweighs the risk of Zekura misusing a locked copy whose every use goes into the chain.

Sovereign. The key is generated in your browser and never leaves it. Zekura only keeps the fingerprint, to check that the right key is being used. Zekura can never restore, not even at your request, and you sign for that. Verification and maintenance are then done by your own verifiers and workers, which do hold the key. That is the model for lawyers, health care, government and anyone with a contractual or legal duty that nobody outside the organisation can ever decrypt.

Shamir: five shares, three needed

The key is split according to Shamir's scheme: with any three shares it can be fully reconstructed, with two you know literally nothing. So you can spread the shares without one person or one place having everything:

• two people (business owner, IT manager or IT partner),
• a safe (physical, on paper),
• the organisation's password manager,
• a notary or lawyer, for those who take it seriously.

Lost two shares? No problem, you still have three. One share stolen? The thief knows nothing.

An untested key is not a key

A key that has been in a safe for three years can be unreadable, miscopied or simply lost. That is why zero knowledge comes with an escrow test: at least once a year, enter three shares, have the key reconstructed in memory, compare the fingerprint and discard the key again. Zekura does that on request and reminds you after a year; pass or fail, it goes into the evidence chain.

Restoring without the vendor

The final test of zero knowledge: can you restore if the vendor disappears tomorrow? With Zekura you install the agent on a clean machine, set the key with your three shares, and the agent can connect with the bucket credentials and restore. We do not need to exist for that. That is how it should be.

Frequently asked questions

Can Zekura read my data in the managed model?

Only by using the locked copy, and that only happens for a restore at your request. Every use is a chain record you can see. Those who do not want even that choose sovereign.

What if an employee with a key share leaves?

One share is worthless on its own. But rotate the key when someone who had one leaves, just as you would change a password.

Is zero knowledge slower?

Encrypting at the source costs some CPU on your server, a few percent during the backup. Restoring is just as fast; decryption happens on the machine that restores.