How it works

We're not asking you to trust a claim. Here's every primitive, named.

No custom cryptography, nothing proprietary — standard, reviewed primitives, used the way they're meant to be used.

Zero-knowledge, precisely

Scilo the company cannot read your secrets

Not as a policy — as a structural fact. The sync server only ever stores ciphertext, KDF salts, and password-verification hashes. There is no code path on it that can decrypt a secret, even under a full server breach or legal compulsion, because the key that could do that is never sent to it.

The envelope

How one key becomes two keys becomes your vault

Master password Device identity (age / X25519) Argon2id + HKDF KEK Vault Key random, per vault Your secret XChaCha20- Poly1305

The master password runs through Argon2id once, then HKDF branches two independent keys from that single derivation: a KEK that wraps your VaultKey, and a separate AuthKey sent to the server as a login credential. They're domain-separated on purpose — a compromised server learns nothing useful toward decrypting your vault.

PrimitiveWhat it does here
Argon2idStretches your master password so brute-forcing it offline is expensive, even if the auth hash leaks.
HKDFBranches the KEK and server AuthKey from one Argon2id run — one slow derivation, two purposes, never mixed.
XChaCha20-Poly1305Encrypts your VaultKey and every secret value. Authenticated — a modified ciphertext fails to decrypt rather than silently returning garbage.
age / X25519Wraps the VaultKey to a device's or teammate's public key, so unlocking a trusted device — or reading a shared org secret — never needs the master password re-typed.

No password re-entry

Unlocking a second device doesn't weaken anything

Enrolling a device wraps your existing VaultKey to that device's own key — it doesn't create a second, weaker path in. The password-wrapped copy still exists and is exactly what a device revocation re-authenticates against.

Real revocation

Losing a device rotates the key. Full stop.

Revoking a device or removing a teammate from a shared org doesn't drop a row from an access list — it generates a brand-new VaultKey, re-encrypts every secret under it, and re-wraps that new key only to whoever remains. The old key decrypts nothing, even if it's still sitting in memory on the device you just lost.

Most tools: remove an ACL entry. A device that already cached the key can go on decrypting everything, forever.
Scilo: rotate the key, re-encrypt everything. The old key is worthless the moment revocation completes.

The trust boundary

What the server sees — and never sees

Sees

  • Encrypted ciphertext blobs
  • KDF salts and parameters
  • Argon2id-derived auth hashes
  • Wrapped-key blobs (device and org)
  • Org membership metadata (who's in, what role)

Never sees

  • Your master password
  • Any plaintext secret value
  • An unwrapped VaultKey
  • A device's or teammate's private key material

Where we're honest about gaps

What's not true yet

Overclaiming here would undercut the entire point of this page. Two things worth knowing before you trust Scilo with real secrets: