SECURITY

How Klos keeps your documents — and what we don't pretend to control.

Honest about what we can promise. Honest about what we can't.

Get Klos

THREE PROMISES

What we control.

  • Only you can see this.

    Klos can't read your documents. Encryption happens on your device before upload. The server holds encrypted blobs; we don't hold the keys.
  • Access ends when you revoke.

    The viewer revalidates share status per fetch. The next attempt after a revoke fails immediately — not eventually.
  • What happens outside Klos is outside Klos's control.

    Screenshots, ZIP exports, what recipients do with a downloaded copy — Klos doesn't pretend to control these. Watermarks deter; they don't prevent.

THE ARCHITECTURE

Three-tier envelope encryption.

Klos's V1 encryption model starts with a Key Encryption Key (KEK) derived from your password via Argon2id and a Content Encryption Key (CEK) that's a random AES-256 key wrapped by the KEK. Private Vault documents use the account CEK; Family Vault documents use document keys wrapped through shared-vault key material for active members.

Document content is AES-256-GCM with a 12-byte IV and a 16-byte authentication tag. The encryption happens on your device before anything reaches our servers.

The server stores encrypted CEK blobs, KEK-keyed commitment MACs, recoverable sharing-key material, Family Vault key envelopes, and encrypted document content. The server never holds plaintext document content, plaintext keys, your password, or your recovery phrase.

What this means in practice: A Klos employee with full backend access cannot decrypt your document content. A storage-layer incident at our infrastructure provider would expose encrypted blobs Klos cannot decrypt.

ENCRYPTION DETAILS

AES-256-GCM. Argon2id. iCloud Keychain. The whole stack, named.

Klos uses AES-256-GCM symmetric encryption for document content. The KEK is Argon2id-derived from your password — the same on iOS and Android, so a new device anywhere can re-derive the KEK from the password alone.

On iOS, the KEK is additionally cached in the device Keychain with iCloud Keychain sync as a convenience layer. On Android, the KEK is held in the Android Keystore.

There is a three-net recovery model: Apple iCloud Keychain can sync your master key across your Apple devices, your Klos account password derives the KEK via Argon2id on any device, and an optional 12-word recovery phrase you generate in Settings → Security can derive an alternate KEK if you forget your password.

We deliberately don't say "bank-grade encryption." Banks don't actually do better than AES-256-GCM. The word "bank-grade" is jargon that doesn't tell you anything you couldn't infer from "AES-256-GCM with a documented Argon2id KDF."

WHAT KLOS CAN'T DO

Limits we won't oversell.

The strongest trust signal a vault can offer is naming its limits before you discover them.

  • Klos cannot prevent a recipient from screenshotting a view-only share. Watermarks deter; they don't prevent.
  • Klos cannot delete a file from a recipient's device after a ZIP export. Once they leave Klos, control leaves with them.
  • Klos cannot recover your account without your password and your recovery surface. There is no back door — we built it that way on purpose.
  • Klos cannot read your documents. Therefore, customer support cannot read them either. When you ask for help, you give us what we need to see; we don't have it.

THREE-MODE SHARING

What each share mode trades.

KLOS-TO-KLOS

End-to-end encrypted in-app share. Recipient must be a Klos user. Revocable per fetch.

KLOS VIEWER LINK

Recipient gets a link; no account required. Revocable per fetch. Per-share key in the URL fragment — the server can't decrypt the document.

iOS SHARE SHEET / ZIP EXPORT

Once delivered, control is with the recipient. Once they leave Klos, control leaves with them.

Get Klos.

Get KlosRead the privacy policy