Math, not policy.
Most workspace tools encrypt data "in transit" and "at rest" — and the vendor holds the keys. Koaich is different. We hold ciphertext. You hold keys. There is no "we promise not to look" in the trust model — there's nothing for us to look at.
When you store something with most workspace tools, the company keeps a copy of the key. They can read it whenever they want, and so can anyone who breaks in or shows them a court order. With Koaich, only your phone or laptop has the key. We store the data, but we can't open it — not for ourselves, not for a hacker who breaches us, not for anyone. The page below describes how we built this for engineers and security teams. The short version is the previous paragraph.
The plain-English version.
For everyone. The technical detail follows.
When you say 'we can't read your data,' what does that actually mean?+
What's end-to-end encryption without the jargon?+
What if I lose my phone?+
Why don't you have password recovery?+
If someone asks for my data, what can you give them?+
Zero-knowledge by construction
Every Koaich vault is zero-knowledge. The encryption keys exist only on member devices; the server has no path to derive or be compelled into producing them. There is no master key. Three keys cooperate to make this work — none of them leave the device chain in cleartext.
- Device identity key · Each device generates its own keypair on-device. For one-to-one messaging and new documents' content keys, the public-key half is a post-quantum hybrid (X25519 + ML-KEM-1024, NIST FIPS 203). Older surfaces are still classical X25519 today — see the post-quantum scope note below. The private half never leaves the device.
- Vault key · Each vault has its own symmetric key, wrapped individually to each member's device public key. Adding a member generates a new wrapped copy. Removing a member triggers a key rotation; the removed device's wrapped copy no longer decrypts new content.
- Per-object key · Each message and document gets its own key. Group messages derive a per-message key from the group key; collaborative vault documents derive from the MLS epoch key (RFC 9420). Files have a per-file symmetric key, wrapped into the message envelope.
Leak one device's key, you compromise that one device. Leak one vault's key, you compromise one vault. There is no key that compromises Koaich.
One-to-one messaging key agreement and new documents' content keys use post-quantum hybrid wrapping today (X25519 + ML-KEM-1024) — the same class and scope as Signal's PQXDH and Apple iMessage's PQ3; ahead of WhatsApp and Messenger, which haven't shipped end-to-end post-quantum. Vault labels, document metadata, documents created before the change, group keys, and group MLS remain classical for now. Out-of-band safety-number key verification isn't shipped yet — the server still acts as the key directory — so this is strong against passive breach and an honest-but-curious server, not yet unconditional against an active malicious server. We don't claim "quantum-proof" or "MITM-proof"; no one honestly can. Full breakdown: Is Koaich post-quantum?
Group messaging (Sender-Key, rotated on removal)
Each group has its own 32-byte group key. That key is wrapped individually for every member (X25519 + XSalsa20-Poly1305 — the same primitive as 1:1 DMs), and each message is encrypted once under the group key. The server stores only ciphertext and never holds the group key.
- · New members get only the current group key, so they can't decrypt messages from before they joined (forward secrecy on join).
- · Removing a member rotates the group key — the admin generates a fresh key and re-wraps it only for the remaining members. The removed person's old key no longer decrypts new messages (break-in recovery on removal).
- · Group messages do not get continuous per-message post-compromise security — the group key is rotated on membership change, not on every message.
When a contractor rolls off your team, removing them rotates the group key; the post-removal strategy thread isn't readable on their device — even if they retain row-level database access, all they see is ciphertext. (Separately, the IETF MLS protocol, RFC 9420, backs collaborative vault documents — not group chat messages.) See Forward secrecy in plain English and What's MLS for the deeper version.
External recipients (people without Koaich)
Koaich isn't a walled garden. Send to someone who doesn't have the app — they get a sealed envelope addressed to their email.
- 1.You compose. Your client encrypts the body under your own ephemeral keypair.
- 2.The server stores the ciphertext plus recipient email — that's it.
- 3.A daily digest email goes out to the recipient with metadata only — sender handle, message count, expiry. No body.
- 4.They click "Open in Koaich." They sign up or enter a one-time code. The body is re-encrypted client-side under their real key.
Digest action links (block sender, decline group, unsubscribe) are HMAC-signed and one-shot. No clickjacking, no replay.
Recovery without vendor-held keys
Mobile: Shamir's Secret Sharing across your own trusted devices. Lose one device — recover from the others. We don't hold a recovery copy.
Web: WebAuthn passkeys backed by your authenticator (Apple ID, 1Password, hardware key). The Koaich web app never sees the private key — the authenticator signs challenges directly. For the full web-tier threat model — SRI, strict CSP, Trusted Types, planned bundle transparency log — see /web-tier-security.
Precision note on key derivation. The passkey is the auth root — it gates access to the app. The encryption root is a separate recovery mnemonic generated at L3 identity enrollment; HKDF off that key derives every wrap key in the stack. Today the passkey gates access to a mnemonic-derived encryption key. A future revision (tracked PLANNED on /web-tier-security) routes key derivation through the WebAuthn PRF extension where supported, so the encryption key is derived directly from the passkey on every unlock — the mnemonic then becomes a backup material handled only at enrollment + Shamir recovery.
There is no password-recovery backdoor. If you lose all your shares, your data is gone. This is what makes "we can't read your data" honest — if we could recover for you, we could also be compelled to read.
Server-side enforcement (without server-side reading)
Account-level quotas — messages per day, external recipients per day, attachment size — are enforced at the database trigger level, not just in the client. A modified mobile build can't bypass them. The server enforces policy without ever decrypting content.
What we see vs. what we don't
What our servers can see
- · Account existence, creation time, registered email.
- · Sender, recipient (handle or email), timestamp, TTL, approximate size — not the content.
- · That a document or file exists — owner, recipients, size, MIME type — not the content.
- · Vault membership: who's in which vault, their role, when they joined or left.
- · Authentication events: logins, IPs, user agents.
- · Per-account usage counters.
- · Invite recipient email addresses on pending vault email invites — cleartext, required by our email delivery provider to actually deliver the email. Deleted from the row once the invite is consumed; the encrypted invite payload (vault name, inviter handle, message) is never readable to us.
- · The fact that you've connected Calendar or Gmail. Your browser calls those Google APIs directly under your own OAuth grant; we allowlist the origins in our CSP so the integration works. We don't proxy, intercept, or store that data — we're not in the request path.
What our servers cannot see
- · The content of any message, document, or file.
- · Vault names + descriptions — encrypted client-side (per-vault DEK, wrapped per-member). Cleartext columns dropped from
public.vaultson 2026-05-17; the server has no decrypt path. - · Vault invite payloads (vault name, inviter handle, message inside the invite email) — encrypted with a key the recipient extracts from the email URL fragment; the server stores ciphertext and never sees the fragment.
- · Vault contact-approval data (the email + display name + handle being approved for vault contact) — encrypted under the same per-vault DEK; only existing vault members can decrypt.
- · Contact list entries (display name, email, note) — encrypted via
address_book.encrypted_payload, wrapped per-user. - · The encryption keys protecting all of the above.
- · Passwords (we don't use them as the recovery primitive).
- · The contents of any third-party API call you make (Calendar events, Gmail messages) — those flow browser↔Google directly under your OAuth grant.
If someone asks for your data: we can produce only what's on our servers — account-existence and authentication metadata. We cannot produce message bodies, document contents, or files. They're ciphertext under keys we don't hold. The math, not the policy, is what enforces this.
The metadata roadmap
The boundary above is an honest snapshot of today. Below is the full inventory by data category — what the server can read today, what's structural metadata it needs to operate, and what's on the roadmap to encrypt further. We'll update this table as items ship.
| CATEGORY | TODAY | DETAIL |
|---|---|---|
| Message content | ENCRYPTED | nacl.box for 1:1, Sender-Key for groups (MLS for vault docs). Server sees ciphertext only. |
| Document + file content | ENCRYPTED | Per-object symmetric key, wrapped to each recipient. |
| Encryption keys | ENCRYPTED | User-held. Server has no path to derive them. |
| Authentication credentials | STRUCTURAL | WebAuthn passkeys on web; no password-derived material reaches us. |
| Account identifiers (email at signup) | STRUCTURAL | Cleartext by design — required for invites and external delivery. Hashing-with-salt under review. |
| Vault labels (name, description) | ENCRYPTED | XSalsa20-Poly1305 ciphertext in vaults.name_ciphertext / name_nonce / description_ciphertext / description_nonce. Per-vault DEK lives in vault_member_label_dek, wrapped per-member under each member's L3 X25519 secret. Cleartext columns dropped from public.vaults on 2026-05-17; the server has no decrypt path. CHECK constraint vaults_ciphertext_required enforces ciphertext-required on every future row. |
| Vault membership (who's in which vault) | STRUCTURAL | Required cleartext for RLS-based access control. Cryptographic membership (auth-credential style) is a long-term option, not v1. |
| Contact list entries (name, email, note) | ENCRYPTED | Stored as ciphertext in address_book.encrypted_payload, wrapped per-user. Server holds an opaque blob; only the contact-list owner can decrypt. |
| Contact discovery (lookup by email) | STRUCTURAL | Lookups go through a salted keyed HMAC (email_hmac) — server never sees cleartext email at lookup time. Caveat: HMAC is deterministic, so the server can still tell two users share a contact. Full zero-knowledge discovery (PSI/OPRF) is a future workstream. |
| Vault invite emails (server-side template fields) | ENCRYPTED | vault_email_invites stores payload_ciphertext + payload_nonce; the cleartext vault_name, inviter_handle, inviter_display_name, invitee_message columns were dropped on 2026-05-17. CHECK constraint vei_payload_required enforces ciphertext-required. The wrapping key is delivered to the recipient via the email URL fragment (#k=…) — browsers don't transmit URL fragments, so the server never sees the key. Recipient email is intentionally cleartext (required by our email delivery provider; flagged in §6). |
| Vault contact-approval requests | ENCRYPTED | vault_contact_approvals stores contact_data_ciphertext + contact_data_nonce; the cleartext contact_email, contact_handle, contact_display_name, reviewer_note columns were dropped on 2026-05-17. CHECK constraint vca_contact_data_required enforces ciphertext-required. Encrypted under the per-vault DEK; only existing vault members (admins + the requester per RLS) can decrypt. |
| Address graph (who messages whom) | STRUCTURAL | Sender/recipient handles are visible. Sealed-sender is a long-term option once anti-abuse is reworked. |
| Per-account usage counters | STRUCTURAL | Required for server-side abuse prevention. |
AI inference traffic is handled separately and is not covered by the table above. See §6.6 On AI features for how AI-generated content is handled.
On AI features
Koaich uses Anthropic's API for AI features (meeting prep, draft composition, summary generation). When you invoke one of these features, the relevant context plus your prompt are sent to Anthropic through our proxy. The proxy does not log or persist prompts or completions on our side, and every request must carry a per-session consent_metadata field naming the surface you opted into.
On Anthropic's side, data is governed by their standard API terms at anthropic.com/legal/commercial-terms. Per those terms, Anthropic does not use API customer data to train its models, and prompt + response data is retained for up to 30 days for trust-and-safety review before deletion. We are separately contracting Anthropic Zero Data Retention (ZDR) for Koaich workloads, which removes Anthropic-side retention entirely. PLANNED — flips to LIVE when the ZDR contract is countersigned.
We deliberately do not claim that AI prompts are end-to-end encrypted or that "our servers cannot see" them. The model has to read them. The cryptographic boundary documented in §6 covers messages, documents, files, vault labels, and contact data — not AI inference traffic. AI features are an optional, explicit-consent surface; when you use them, you are sending data to our LLM provider under the terms above.
What we don't have (yet)
- · No password recovery (intentional)
- · No vendor-side content audit log (intentional — would compromise the core guarantee)
- · No admin "compliance and audit" portal (roadmap)
- · No BAAs out of the box for healthcare (roadmap)
- · No SOC 2 / ISO 27001 / PCI certifications (roadmap — late 2026)
- · Mobile passkey native integration (roadmap — web tier already passkey-only; mobile uses email + password until Apple Passkeys / Android Credential Manager ship in the next release)
- · WebAuthn-PRF-derived encryption keys (roadmap — today the passkey gates access to a mnemonic-derived key; PRF would route key derivation through the passkey directly. See §4 Recovery precision note.)
- · Encrypted IndexedDB at rest (roadmap — local browser storage currently cleartext; PRF-derived wrap layer is the next web-tier hardening item)
- · Trusted Types CSP directive (roadmap — blocked by one same-origin innerHTML write in the rich-text editor; iframe-isolation refactor in flight)
- · Reproducible builds + bundle transparency log (roadmap — Sigstore Rekor integration)
Want the architecture brief?
The half-pager that goes deeper than this page — cipher choices, key derivation, threat model — is available to security reviewers at prospective customers on request.
Join the waitlist