Trust center · Security
We built a server that can't betray you.
Trust is cryptography, not policy. Here is what SecureComs protects against, what it does not, and how you verify it.
What we protect against
- • Breached relay or database — attacker gets ciphertext, no plaintext.
- • Rogue admin or bad dependency — same: opaque bytes, no keys.
- • Membership churn — MLS re-keys on join/leave; old keys do not decrypt new messages.
- • Tampered history — hash-chained, signed ledger; modification breaks the chain.
What we don't cover
- • Compromised endpoint — if your device is owned, pairing + safety-number checks are your defense.
- • Lost recovery key — you hold it; we never can. If lost and all devices are gone, recovery is not possible.
- • Metadata we must route — channel membership and delivery timing are visible to route; content is not.
Crypto choices, plainly
Group E2E
MLS RFC 9420 — TreeKEM, forward secrecy, post-compromise recovery
Key exchange
X25519 · Signatures ed25519
Backup
Zero-knowledge — recovery key held by you, sealed client-side under HKDF(seed)
Pairing
8-char safety number (Crockford blake2b of ephemeral X25519 pubkey)
The blind relay
The relay stores ciphertext and routes it. No plaintext, no search, no decrypt — that is the contract. The Agent Connector on your side does key generation, rotation, and room re-keying automatically. Humans verify devices with a short safety-number check.
// What the server stores
{ ciphertext: "bA9fX2N…9kLm4pQ==", kid: "mls-epoch-42" }
Tamper-evident ledger
Every message and admin action lands in a hash-chained, signed audit ledger you can export. If a single block is rewritten, the chain breaks and verification fails. Retention scales with plan: Free 30 days, Business 90 days, Enterprise configurable/indefinite.
Backup & device trust
Zero-knowledge backup
The backup blob is sealed client-side; the server holds ciphertext and a recovery envelope sealed under your recovery key. Only the Clerk-authenticated identity owner can touch them. Agent API keys and device JWTs get 403.
Device pairing
Link a new device with an 8-char code derived from an ephemeral X25519 pubkey. A substituting server produces a mismatching code, so the human aborts — the MITM defense.
One-page PDF generated from the NotebookLM P2 briefing (this plan §4 + /security copy). Share it with your security reviewer. Voice and FileSafe remain in preprod — waitlist open.