KoaichJoin waitlist
Security

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.

The plain-English version.

For everyone. The technical detail follows.

When you say 'we can't read your data,' what does that actually mean?+
Your data — messages, documents, files, AI drafts — is locked before it leaves your device. Only you and the people you've granted access to hold the key. Our engineers, sitting at our servers with full admin access, see ciphertext where your content lives. They see the structural metadata the database needs to function — accounts, vault membership, vault labels you've assigned, timestamps — but never the content itself. There is no master key we could pull out; we deliberately designed against ever having one.
What's end-to-end encryption without the jargon?+
Imagine writing a letter, sealing it in an envelope, and handing it to a courier. The courier delivers it. The courier never opens it. With most workspace tools the courier reads every envelope, sometimes makes copies, and stores those copies forever. We don't.
What if I lose my phone?+
Your data has a key — like a house key. We never hold a copy. But your other devices each hold a piece of a spare. As long as you have one other Koaich device, you can rebuild the spare and recover. If you lose every device at once and didn't save your recovery codes, your data is gone. We chose this trade-off deliberately: if we held a master spare, anyone who broke into our office could too.
Why don't you have password recovery?+
Every tool that lets you 'reset and get back in' is keeping a copy of your data somewhere they can decrypt — that's how recovery works. We chose not to have that copy. Trade-off: you have to take device backup seriously. Benefit: there's no master copy of your data on our servers waiting to be breached, requested, or copied.
If someone asks for my data, what can you give them?+
Only what's on our servers — metadata and ciphertext. We can't decrypt message bodies because we don't hold the keys. The math, not the policy, is what enforces this.
§ 1

Three encryption tiers

Koaich uses a three-tier key hierarchy. There is no master key that compromises everything.

  • L1 (device tier) · Every device has its own keypair. Generated on-device. The private key never leaves it.
  • L2 (vault tier) · Each vault has its own symmetric key, wrapped to each member's device public key. Adding a member generates a new wrapped copy.
  • L3 (per-object tier) · Each message and document gets its own key, or derives from the MLS epoch key for groups. 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.

§ 2

Group messaging via MLS

Groups use the Messaging Layer Security protocol — IETF RFC 9420.

  • · Every membership change rotates the group key forward.
  • · Past members can't decrypt future messages (forward secrecy).
  • · A compromised member can't silently read past messages without resyncing keys (post-compromise security).

When a contractor rolls off your team, this quarter's strategy thread isn't readable on their device. Past members can't decrypt content from epochs they weren't in — even if they retain row-level database access, all they see is ciphertext. See Forward secrecy in plain English and What's MLS for the deeper version.

§ 3

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. 1.You compose. Your client encrypts the body under your own ephemeral keypair.
  2. 2.The server stores the ciphertext plus recipient email — that's it.
  3. 3.A daily digest email goes out to the recipient with metadata only — sender handle, message count, expiry. No body.
  4. 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.

§ 4

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.

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.

§ 5

Server-side enforcement (without server-side reading)

Per-tier limits — 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.

§ 6

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 labels (the names + descriptions you assign your spaces) — not what's inside them.
  • · Vault membership: who's in which vault, their role, when they joined or left.
  • · Authentication events: logins, IPs, user agents.
  • · Per-tier usage counters.

What our servers cannot see

  • · The content of any message, document, or file.
  • · The encryption keys protecting them.
  • · AI prompts and completions when they touch user data.
  • · Passwords (we don't use them as the recovery primitive).

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.

§ 6.5

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.

CATEGORYTODAYDETAIL
Message contentENCRYPTEDnacl.box for 1:1, MLS for groups. Server sees ciphertext only.
Document + file contentENCRYPTEDPer-object symmetric key, wrapped to each recipient.
AI prompts on user contentENCRYPTEDClient-side context; LLM proxy doesn't retain.
Encryption keysENCRYPTEDUser-held. Server has no path to derive them.
Authentication credentialsSTRUCTURALWebAuthn passkeys on web; no password-derived material reaches us.
Account identifiers (email at signup)STRUCTURALCleartext by design — required for invites and external delivery. Hashing-with-salt under review.
Vault labels (name, description)PLANNEDCiphertext columns deployed (2026-05-17); dual-write to vaults.name_ciphertext / name_nonce is live on the server. Flipping to ENCRYPTED here after end-to-end UI smoke verifies client decrypt round-trip.
Vault membership (who's in which vault)STRUCTURALRequired cleartext for RLS-based access control. Cryptographic membership (auth-credential style) is a long-term option, not v1.
Contact list entries (name, email, note)ENCRYPTEDStored 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)STRUCTURALLookups 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)PLANNEDCiphertext columns deployed (2026-05-17). vault_email_invites now stores payload_ciphertext + payload_nonce; per-invite random key delivered via URL fragment (server never sees it). Flipping to ENCRYPTED here after end-to-end UI smoke verifies the invite-link → decrypt → render flow.
Vault contact-approval requestsPLANNEDCiphertext columns deployed (2026-05-17). vault_contact_approvals now stores contact_data_ciphertext + contact_data_nonce. Flipping to ENCRYPTED after UI smoke verification.
Address graph (who messages whom)STRUCTURALSender/recipient handles are visible. Sealed-sender is a long-term option once anti-abuse is reworked.
Per-tier usage countersSTRUCTURALRequired for server-side abuse prevention.
§ 7

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)
  • · Vault labels (names + descriptions) are cleartext server-side today (in flight — content already E2E, label encryption shipping in current workstream)
  • · Vault invite emails + vault contact-approval requests hold a small set of cleartext fields server-side (vault name, inviter handle, contact email) so the email template can render them (in flight — encryption shipping in the same workstream as vault labels)

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