Skip to content
TalXTalX

The security model

A security promise without a stated threat model is worthless. This page therefore says first what TalX protects against – and in the same breath, what it does not.

What TalX protects against

Section titled “What TalX protects against”
Adversary Protection
Eavesdropping on the radio path – someone on the same Wi-Fi, within Bluetooth range, on the mobile network complete. What leaves the device is finished ciphertext. No transport holds a key.
The relay operator reading along ruled out. They receive nothing but AES-GCM ciphertext and can neither read it nor alter it undetected.
Later theft of a key (forward secrecy) yes. Every message has its own key, spent immediately – from the very first message onwards.
A one-off compromise (post-compromise security) yes. The ratchet recovers by itself at the next change of direction.
“Harvest now, decrypt later” with a quantum computer yes. ML-KEM-1024 is mixed into the root key in addition to the classical method.
Man-in-the-middle while connecting yes – via J-PAKE for code pairing, and verifiable through the safety number.
A stolen, switched-off device yes. Database and attachments are encrypted; the key depends on the secure element of that specific device.
A copied app folder, a copied backup yes. Without the secure element of this device nothing can be unwrapped.
Claiming rights in a group yes. Every device checks the sender’s role for itself.
A tampered language model from the network yes for future downloads – checksum and size are built into the app.
Someone you no longer want to hear from yes. A blocked contact gets through with nothing – not even in shared groups – and a block survives a re-pairing.

What TalX does not protect against

Section titled “What TalX does not protect against”
Adversary Reality
The relay operator sees metadata yes, they do. Which identifiers communicate with each other, and when. Mitigation: run it yourself, or use TalX purely offline.
Someone on the same local network sees presence yes. The mDNS announcement shows which TalX identifiers are on the network. Content stays encrypted.
An unlocked device in someone else’s hands no. The wrapping key is deliberately not bound to user authentication so that background reception keeps working. Mitigated by the separate app lock.
A rooted device with active malware no. That applies to every app.
The recipient themselves no. Anyone allowed to read a message can photograph it, forward it or keep it. “View once” changes nothing about that.
An adversary with access to the Play Store delivery path partly. There are no reproducible builds – you cannot independently verify that the shipped app came from exactly this source code.
Subtle protocol flaws that nobody internal spots open. That is precisely what independent audits are for – and precisely what is missing.

User-facing protections

Section titled “User-facing protections”
  • Safety number – in the chat, via the shield symbol. Compare over a second channel, then mark as verified.
  • Warning on key change – if the number changes unexpectedly, TalX says so in the chat.
  • App lock – biometrics or device code before opening.
  • Screenshot and recents protection – on by default; the app appears in the overview as a black surface.
  • Reset the encrypted session – when a session has fallen out of step for good.
  • Block a contact – nothing is accepted from them any more, and nothing goes out.
  • Delete a contact – removes the contact, the history and all associated key material, in groups too.
  • Switch off offline connections – when the device should not be visible on unfamiliar networks.

Content moderation

Section titled “Content moderation”

TalX is a pure direct-messaging service: there are no public channels, no search for people, no recommendations and no way to be contacted by strangers. Communication requires that two devices deliberately connected beforehand.

On top of that there is a filter against far-right display names and status texts – with detection of typical character substitutions and, this is the point, on receipt as well. Bypassing the filter with a modified app gets you nowhere: the other side filters too.

If you no longer want to hear from someone, you have two options:

  • Block (contact info → block, confirmed in two steps). Nothing is accepted from a blocked person any more – no messages, no attachments, no calls, no profile or presence details, not even in shared groups. In the other direction nothing goes out, and anything pending is dropped from the queue. The history is kept.
  • Delete (long-press in the chat list). Removes the contact along with the history and key material from the device.

A block survives a re-pairing, even with a new key – otherwise it would be worthless: anyone blocked would only have to reinstall. It applies to the person, not the key.

Read on

Section titled “Read on”