The trust model, stated honestly
What DChat defends against, and the list of things it does not.
The trust model, stated honestly
A threat model is only useful if it names the adversary on both sides of the line. Here is DChat's, without the parts it does not cover moved into small print.
None of this is independently verified yet. Nothing in the specification or on this site has been reviewed by an outside cryptographer or security firm, there is no formal verification of the protocol, and there is no paid bug bounty program - reports are still welcomed and credited, but that is a different thing from a bounty. Treat every claim below as a design intent that has been reasoned about, not one that has been externally tested.
- A passive network observer. Message content and 1:1 call media are encrypted end-to-end before they leave the device; an observer on the wire sees ciphertext and the cleartext envelope fields, nothing more.
- A curious relay operator. A relay holds ciphertext, connecting IPs, and cleartext routing metadata - never a decryption key. Compromising a relay yields metadata and traffic, not conversations.
- A server breach yielding plaintext. No server stores message plaintext. Relays hold ciphertext for undelivered messages for up to 14 days and nothing more. Plaintext lives only on participants' own devices, in a SQLCipher-encrypted database.
- An adversary substituting the distribution channel. Because no privileged server holds decryption keys, capturing DChat's infrastructure cannot retroactively unlock past ciphertext. It could still push a malicious client update - that risk is a compromised endpoint, addressed on the right.
- A stolen, locked device. Keys are wrapped under a device master key in platform secure storage (Android Keystore) and stretched with PBKDF2-HMAC-SHA256; App Lock adds a biometric gate on top. An attacker with the device but no unlock credential does not get the keys.
- Traffic analysis. No padding to fixed sizes, no cover traffic, no delay mixing. Message timing and approximate size are observable to anyone watching the network.
- Social-graph inference by a relay. Sender DID, sender public key and chat id travel in cleartext on every envelope, letting a relay link messages to the same sender over time even without decrypting a single one.
- A compromised endpoint. Malware or physical access to an unlocked device reads everything, because at that point it is you. No messenger solves this.
- Post-compromise security. Key agreement is static-static ECDH with no ratchet. A compromised chat key exposes that key generation's whole window - up to 10,000 messages or 30 days by default - not a single message, and recovery requires a manual rotation.
- Group-call media at the SFU. As covered above, the Janus SFU decrypts and re-encrypts group-call media in the middle of the call.
- Anything past the rotation window. The 10,000-message / 30-day default cap bounds exposure; it does not eliminate it, and the exposed window itself is coarse-grained, not per-message.
The honest summary is the same one security.html gives: DChat's architecture removes the operator as a point of trust, and that is the part it does well. Its message-layer cryptography is conventional and correctly composed as far as this specification describes, but it is less advanced than a ratcheting design, and none of it has been externally audited yet. Those are two different claims, and this page tries not to let them blur into one reassuring sentence.
Full parameter-level detail: Spec §8 - known weaknesses. Full audit status and disclosure policy: Security - what DChat does not protect against.