KeyvaciSecurity architecture
Don't trust us. Check us.
Every claim on this page is a property of the design, not a policy we promise to follow. Policies change with management; mathematics does not. Here is exactly what happens to a secret you store in Keyvaci.
The core mechanism
A secret's journey, end to end
Keys are born on your device
At enrolment, your master password runs through Argon2id (64 MiB memory, deliberately expensive to brute-force) to derive your master key, which protects your personal X25519 encryption keypair and Ed25519 signing keypair. The master password and master key never leave the browser.
The organisation countersigns
An administrator verifies your key's fingerprint with you over a separate channel and countersigns it with the organisation signing key. From then on, every device in your organisation can verify your key is really yours before trusting it with anything.
Entries are sealed client-side
Each vault has its own key. Every entry, including the vault's name, is encrypted with XChaCha20-Poly1305 authenticated encryption on your machine. What travels to us, and what we store, is the ciphertext.
Sharing is signed cryptography
Sharing a vault encrypts its key for the recipient's public key, after the countersignature check, and signs the grant so it cannot be redirected to a different key. Revoking re-encrypts the vault under a fresh key.
The honest inventory
What our servers hold
A zero-knowledge claim is only as good as its inventory. This is ours.
| Data | What we actually store | Can Keyvaci read it? |
|---|---|---|
| Vault entries (passwords, notes) | XChaCha20-Poly1305 ciphertext | No |
| Vault names | Ciphertext, encrypted like entries | No |
| Your master password | Nothing. It is never transmitted | No |
| Private keys | Ciphertext sealed by your master key | No |
| Organisation recovery & signing keys | Nothing. Generated and kept on your side | No |
| Public keys and countersignatures | Plaintext (they are public by design) | Yes |
| Names and emails of members | Plaintext, needed to run the account | Yes |
| Audit events (who did what, when) | Plaintext metadata, append-only | Yes |
| Sign-in links (email sign-in only) | SHA-256 digest only, usable once, dead five minutes after it is sent. There is no sign-in password to hold | Digest only |
The consequence, stated plainly: a full compromise of Keyvaci's database yields ciphertext, public keys, and metadata. The material needed to decrypt your vaults is not there to be stolen.
Defence in depth
Around the cryptography
Step-up on reveal
Reading a credential requires recent authentication, with optional TOTP. Session tokens alone never open a vault entry.
Rate limits with a purpose
Reveals and vault opens are rate-limited per user, so even a hijacked, stepped-up session cannot bulk-export an organisation's secrets.
Edge protection
All traffic passes a WAF (managed rule sets, IP reputation, rate rules) in front of the API, and the API origin rejects any request that did not come through it.
Tenant isolation
Every record is keyed by organisation, checked on every request, and covered by cross-tenant isolation tests that run in CI.
Append-only audit
The audit service's own database permissions allow writing new events and nothing else. Tampering is not a policy violation; it is a permission error.
Strict sessions
Decryption keys live in memory only, wiped on lock, after 15 idle minutes, or when the tab hides. Sign-in freshness and audience are verified against the IdP's keys on every request.
More clients, same rules
What the extension and the phone are not allowed to do
Adding a browser extension and a mobile app is where most vaults quietly loosen their own rules, because filling a password conveniently is easier when something is holding a key for you. These are the places we refused to, and what each refusal costs.
| Rule | How it is enforced |
|---|---|
| One implementation of the cryptography | The extension and the phone consume the same encryption and the same verified read chain as the web app, as source. There is no second copy to drift, and no client with weaker parameters. On the phone this is why key derivation runs natively at the full 64 MiB rather than being reduced to something a browser engine could manage |
| An entry that fails a signature check is discarded | The web app can afford to show a warning next to something questionable. An autofill menu cannot hold that conversation, so anything that fails the organisation, grant, or author signature check is dropped and never offered. Filling a password from an unverified source is the one thing these clients must never do |
| Every reveal is audited | Showing, copying, and filling all go through the same audited reveal as the console, including fills into other apps on the phone. A second client is not a way around the log the product is sold on |
| Autofill cannot run without a person | The iOS provider refuses the silent path the system offers, and asks for the master password in its own process every time. Answering that request silently would mean a key was being stored somewhere for it |
| The menu only knows the site you are on | Matching is by exact host or a true parent and child relationship, never by substring, and the page's own origin is taken from the browser rather than from anything the page can claim. A misdirected click on a hostile site can only fill a credential that already belonged to it |
| Keys expire on a deadline, not on idleness | Ten minutes after unlocking, the extension and the phone erase their keys whether or not you returned. The phone also clears them the moment the app leaves the screen, so the app switcher never holds an open vault |
| The vault never sees your company password | Signing in with Microsoft opens a window owned by the browser or the operating system, which the extension cannot script and cannot read |
One honest exception, and it is the reader's to make: turning on Face ID stores your master password on that one device, guarded by the device's secure hardware and invalidated automatically if the biometric set changes. It is off until you switch it on, the app states the trade at the point of consent, the master password is still asked for every 30 days and immediately after any password change, and there is never a state where biometrics are the only way in.
Limits, stated out loud
What zero-knowledge does not do
A security page that lists only strengths is marketing. These are the boundaries of the model, and what we did about each.
Your devices are yours to secure
Decryption happens on your machines, so malware on a member's device can see what that member sees. Auto-lock, auto-hide, clipboard clearing, and reveal audit narrow the window; they cannot remove it.
Recovery is a real power
The organisation recovery key can restore any member's keys, which means it could read their vaults. We tell every member this at enrolment, in plain words, and every recovery is audited. Guard that kit like the master secret it is.
Lost keys are lost data
If a member forgets their master password and the organisation loses its recovery kit, that data is gone. Nobody, including us, can bring it back. We repeat this warning at signup because it is the honest price of a server that cannot read your data.
Put the architecture to work
14 days, every feature, no card. Your security team is welcome to ask us hard questions at keyvaci@xnorgroup.com while you evaluate.