12. Security & Threat Model

Written for Sam. Every claim here must be one we would defend in a public audit.

What Kontaks defends against

12.2 What the addressing claim does and does not cover

What we can and cannot say about contacts

"We never know your contacts" is not a claim this product can make. The precise position:

The exception is groups, and it is structural. A group post is one batched request carrying an envelope for every member's every device. That batch is the membership list, delivered to us in a structured request, every time anyone posts. Sending 87 separate requests instead would cost battery and latency and they would still arrive on one connection within the same second — so group membership exposure is the price of groups working at all, not a defect we have left unfixed.

Kontaks removes the reusable address. It does not make you anonymous to the people you talk to. Inside a room, members necessarily see one another. The honest inventory:

None of it grants reachability, and all of it dies when they leave — but "no identity" would not be a defensible summary of that table, and this document should never make one.

12.2.a What the server can infer about who talks to whom

The schema stores no contact list: routes are one-way rows with no field linking the two directions of a relationship, and no field grouping one person's routes (§17). That is a true statement about storage and a much weaker one about practice.

On batching, specifically — this was an implicit choice and it should be an explicit one. The alternatives are real and none is free:

We batch, and we say so. Pretending otherwise would be worse than the exposure. The honest claim is "we do not record a contact graph" — never "we cannot determine one."

12.2.b This document is not the cryptographic specification

CRYPTO.md is authoritative for protocol. This PRD is the product view.

The protocol is necessarily described across several sections here — key inventory in §6.1.a, pairing in §6.2, primitives and novelty in §12.3, the inventory below, and wire-level records in Appendix A. A specialist cannot review a protocol scattered through a product document, and an implementer working from these sections alone will fill gaps by guessing.

So: write CRYPTO.md before the crypto code (§12.4), make it self-contained, and treat it as the single reviewable artefact. Where this document and CRYPTO.md differ on protocol, CRYPTO.md wins and the PRD is the defect.

12.2.c What Kontaks does not defend against — stated because pretending otherwise is worse than the gap

1. A contact behaving badly. They can screenshot, relay, or read your messages aloud. They are a legitimate recipient; cryptography has nothing to say about it.
2. Recognition by the people you have paired with or share a room with. The name you presented, your voice, your avatar, your writing, the fact of your membership, and who vouched for you are all visible to the person or room you presented them to — and to a determined observer there, that may be enough to identify you in the ordinary sense. What they cannot do is turn any of it into a way to reach you, find you, or link you to another room (§12.2). Reusing one name and avatar everywhere creates that link, and the product pre-fills a default name, so reuse is the path of least resistance rather than a deliberate act (SPEC §6.3, D23, D25). The link is legible only to someone already in both relationships; it is still not a lookup key and still yields no route to you.
3. Traffic-analysis metadata, and group membership in particular. The server sees which device is awake, envelope sizes, and timing per route, and group sends arrive batched, which reveals membership directly (§12.2.a). The two directions of a pair are stored as unrelated rows — we do not record the link — but we do not claim it cannot be determined.
4. A compromised endpoint, or a device stolen while unlocked. Malware, a jailbreak, or a snatched unlocked phone reads everything on that device. The app lock and panic wipe (§6.1.2) shrink the window; nothing closes it. What we do bound is the blast radius: it is one device on your keyring, revocable in seconds, with no action required from any contact — unlike a SIM swap, which takes every relationship at once and cannot be undone.
5. Your recovery secret. It is the one bearer credential in the system. We minimized what it can do (sign roster entries only — it cannot read, send, or decrypt history) and made using it slow and loud (§6.1.3), but someone who obtains your 12 words, or your Apple/Google account together with a device passcode, can enroll a device. Tier 4 (no recovery at all) exists for users who would rather lose their contacts than carry that risk.
6. A pre-compromised push token. Apple and Google know a device received a push and when.
7. Coerced disclosure of your own device. Rubber-hose applies as it always does. There is no duress mode; the panic wipe (§6.1.2) is a wipe, not a plausible-deniability mode.
8. A malicious build. Reproducible builds and a published binary transparency log are worth doing and are not achievable for an iOS app today. Decided: we publish build provenance instead — signed GitHub Actions attestations and published artifact hashes for every release, so a build is tied to a commit even though it cannot be byte-reproduced. Sam will ask; that is the honest answer.

Cryptographic inventory

12.3 Novelty is deliberately minimal

The probability of being broken, and the cost of reviewing it, both scale with how much of the cryptography is ours. Almost none of it is.

What remains to review is protocol logic, not cryptographic mathematics: whether the roster chain really stops a rogue device, whether the recovery flow has a hole, whether the invite entropy budget is right, whether the fingerprint binding really prevents a server MITM. A strong security engineer answers those in a few days.

For a first version, being boring buys more risk reduction than being audited does. An unaudited app built on libsignal with no hand-rolled ratchet and no PAKE is far less likely to be broken than an audited app full of original constructions.

12.4 External review — optional, staged, and not a launch gate

Nothing gates us. No store, regulator, or law requires a third-party cryptographic audit for a consumer messaging app. Signal, Telegram, Threema and Session all shipped before one. We can write CRYPTO.md, build, launch, reach 10k users and take revenue with zero review spend.

"Optional" means nobody will stop you, not that there is no downside. If the protocol is broken we find out when someone else finds it, and for a privacy product that failure is terminal rather than recoverable. The natural trigger is affordability, not principle: at ~1,000 subscribers the product takes ~$3,000/month and a review is two to three months of revenue — at which point skipping it is a choice, not a constraint.

Timing note: the crypto is not the first code written. App shell, pairing UX, call plumbing and push infrastructure come first — months of work. "Before you write the crypto code" is realistically month three or four, by which point there may already be beta signal on the thing that actually determines viability.

12.5 What we may and may not claim publicly

The core pitch — "no spam calls, because there is no number to leak" — is a claim about architecture, verifiable by anyone who opens the app. No cryptographer needs to certify it. The line is describe what you built; do not guarantee an outcome.

The encryption line is fine unreviewed if it is true — deception requires a false statement, not an unverified one. Exposure comes from guaranteeing outcomes, not from describing an implementation.

Be precise about libsignal, because over-claiming here invites exactly the criticism we least want. We use libsignal for 1:1 sessions. Group messaging is pairwise fan-out of those 1:1 sessions — it is not Signal's group protocol, and there is no sealed sender. Saying "uses the Signal Protocol" without qualification reads as "audited like Signal," which is not a claim we can support.

And anonymity is not one of our claims. People in a room see each other's chosen names, voices and avatars (§12.2). Marketing may say that nothing shared in Kontaks can be used to reach or find someone elsewhere; it may never say that users are anonymous or untraceable, because inside a room they are neither.

Two disclosures we cannot opt out of: the Apple Privacy Nutrition Label / Play Data Safety forms (see §13 — "Data Not Collected" is very likely not the right answer; do not tick Play's independent-security-validation badge), and US encryption export paperwork, which is free but must be answered correctly or a submission is blocked.