Security

We built KeyLynk so we couldn't read your secrets — even if we wanted to.

Not a policy. Not a promise. A cryptographic guarantee enforced by where the keys live — and they don't live on our servers.

The Account Key model

Your vault isn't protected by one secret — it's protected by two, and we only ever hold half of that story, encrypted. Your master password lives in your head. Your Account Key is a separate, randomly generated 128-bit value created on your device the moment you sign up. Neither one alone unlocks anything.

Master password + Account Key are combined and run through PBKDF2-SHA256 at 100,000 iterations
That derivation produces a 256-bit AES-GCM key — entirely inside your browser, via the WebCrypto API
The derived vault key is never sent anywhere, and is never written to disk, localStorage, or a cookie
Losing the browser tab or refreshing the page clears it from memory — it is re-derived from your password and Account Key each time you unlock the vault

vault.tsTypeScript

const combined = masterPassword + accountKey;

const vaultKey = await crypto.subtle.deriveKey(
  { name: 'PBKDF2', salt, iterations: 100_000, hash: 'SHA-256' },
  keyMaterial,
  { name: 'AES-GCM', length: 256 },
  true, ['encrypt', 'decrypt']
);

// vaultKey never leaves this scope

What “zero-knowledge” actually means here

Not a tagline. Here's exactly what our servers do and don't see.

Every credential, AES-256-GCM

Each secret you store is encrypted client-side with your vault key before it ever reaches our servers, using a fresh random IV per credential.

We store ciphertext, full stop

Our database holds encrypted blobs and a salt. There is no vault-key column, no master-password hash we could brute-force, nothing to decrypt from our side.

Compelled disclosure gets ciphertext

If we received a breach or a legal demand for a vault, what we could hand over is encrypted data we cannot read — not your secrets.

How an agent gets a secret — without ever getting your vault key

Scoped agent tokens are a second, independent key — not a copy of your master key, and not a password an agent could reuse anywhere else.

1
Creating a token generates its own random 256-bit AES-GCM key on your device. The credentials that token can see are re-encrypted with that token's key, not your vault key.
2
What we store server-side is a SHA-256 hash of the token string — not the token itself. A database read can't be turned back into a working credential.
3
When an agent redeems a token, our endpoint looks up the hash, checks it hasn't expired, and returns the pre-encrypted blobs for exactly what that token is scoped to. The agent decrypts locally with the token key it already holds — our server never decrypts anything to serve the request.
4
Every redemption — valid or not — gets a uniform response. We don't tell a caller whether a token exists, only expired, or was never valid, so a wrong guess can't be used to probe for real tokens.
5
Every successful redemption writes an audit log entry per credential released, with actor, timestamp, and requesting IP. You can see exactly which token pulled which secret and when.

The honest tradeoff of zero-knowledge

Because we genuinely cannot read your vault, we also genuinely cannot reset it for you. There is no “forgot password” flow that gets your secrets back — if we could recover them, we wouldn't be zero-knowledge. That's the whole point, and it cuts both ways.

That's why every account gets an Emergency Kit at signup: your Account Key and salt, packaged for offline storage, separate from your master password. Keep both somewhere safe. Losing your master password with the kit in hand is recoverable. Losing both is not — by design, not by oversight.

Found a problem?

If you find a security issue in KeyLynk, we want to hear about it before anyone else does. Report it through the form below and we'll respond as a priority.

See it in your own vault

Free tier, no card required. Encrypted before it leaves your browser, from the first secret you add.

Create your free vault