A security claim you cannot check is marketing. The protocol
is published in full, the test vectors are in the repository, and the
threat model states the limits as plainly as the strengths.
What Z is designed to withstand
A hostile or seized relay: it holds only ciphertext, in RAM,
addressed to hashes — and with sealed sender it is not told who sent
what.
Recorded messages decrypted later, including by a quantum
computer: from a conversation's first round trip, every message key mixes
in an ML-KEM-768 secret. The opening exchange, contact requests, the invite
ceremony and linking a device are classical; the threat model lists
them.
A stolen key: the double ratchet moves keys forward
constantly, so a compromise reaches neither past nor future messages.
A substituted key: safety numbers let two people detect it
themselves, and device-list changes are gossiped between contacts so a
silently added device is visible.
A lost device: the vault is encrypted, optionally behind
biometrics or a passphrase, and can be wiped.
What it cannot do
These are real limits, not hypotheticals, and they are in the published
threat model rather than buried:
A compromised device defeats everything. Disappearing
messages and local encryption protect a lost phone, not one running an
attacker's software.
The relay sees transient metadata. IP addresses,
timing and padded sizes pass through memory. Z does not record or analyse
them, and nothing is stored to hand over — but a network observer still
sees that a device is talking to a relay.
Trust starts out of band. If a contact code is
swapped before it reaches you, you verified the wrong person. That is what
safety numbers exist to catch.
The transparency log's witness is new, and the app
watches it only in Settings. Device-list changes are published to a public,
append-only key-transparency log; the app pins the log's key and, from the
release that carries it, the key of a witness somebody outside the project
runs, which checks the log and co-signs what it has verified. The app
reaches that witness through our own domain. When the witness goes quiet
(no answer, or only a record a day old) the app says so in Settings, not
on the home screen, so on that path a reader who never opens Settings is
still trusting us not to show the
log selectively. Safety numbers and contact gossip
catch a swapped key regardless.
Group membership is asserted by the group's admin
over their authenticated channel — there is no cryptographic group
state.
The transparency log learns which groups of accounts you
check. Checking a contact's device list means asking the log about
them. The app asks for groups of 32 to 64 accounts at a time, among decoy
groups it keeps, and never for anyone by name — so whoever runs it, us for
the built-in log, learns which groups you ask about, not who your contacts
are; versions before this one asked by name. It is on by default;
Developer mode in Settings turns it off.
Cloudflare sits in front of this service. It
terminates the encrypted connection to the relay and the log, so it sees
connection metadata — your IP address, the mailbox IDs you use and send to,
and which groups of accounts you ask the log about — though never message
contents.
How the claims are checked
The wire protocol is frozen and specified byte by byte, and pinned by
known-answer test vectors. Those vectors are reproduced on every change by
three independent implementations: the app's own, a clean-room implementation
written from the specification alone that shares no code with it, and
reference implementations of the post-quantum primitives. If any of them
disagrees, the build fails.
Independent audit
Z has not yet had an external security audit. The scope brief and
the threat model are published so that one can start from a clear statement
of what is claimed. We would rather say this plainly than imply an assurance
that does not exist.