Our security model
How DChat protects your messages, your keys and your account.
Our security model
A security model is only useful if it is specific. This page names exactly what DChat protects, how, and with which primitives, so you can check it against the specification rather than take a slogan on trust.
What DChat protects
Your conversations, from anyone on the network. Message content and one-to-one call media are encrypted on your device before they leave it. An observer on the wire sees ciphertext. There is no key anywhere in the network that could turn it back into text.
Your conversations, from the people running the infrastructure. A relay holds ciphertext and routing information, never a decryption key. Compromising a relay yields traffic, not conversations. This is a property of where the keys live, not a promise about how operators behave.
Your history, from a server breach. No server stores message plaintext. Relays hold ciphertext for undelivered messages for up to 14 days and nothing else. Plaintext exists only on the devices in the conversation, in an encrypted local database.
Your past messages, from a future key compromise. Chat keys rotate automatically every 10,000 messages or 30 days, whichever comes first, so any single key covers a bounded window rather than your entire history. Several comparable messengers never rotate keys at all.
Your account, from us. DChat cannot read your messages, cannot suspend or terminate your account, and cannot reset a lost recovery phrase, because it never holds your keys. Capturing DChat's own infrastructure would not unlock a single past message.
Your keys, on a stolen device. Keys are wrapped under a device master key held in the platform's secure storage and stretched with PBKDF2-HMAC-SHA256, with App Lock adding a biometric gate. An attacker holding a locked device without the unlock credential does not get the keys.
The primitives, in full
secp256k1 for identity and ECDH key agreement, HKDF-SHA256 for key derivation, and ChaCha20-Poly1305 for encryption with a 256-bit key, a fresh 96-bit random nonce per message and a 128-bit authentication tag. Groups use an N-sender-keys model, so every member holds their own sending key and no server ever handles a group key. Every parameter is published in the cryptographic specification, which is more than most messengers disclose at all.
One design note worth knowing. A call with more than two people routes through a media server, which is what allows group calling to scale beyond a direct connection. Group calls are therefore encrypted in transit rather than end to end. One-to-one calls connect the two devices directly with no server in the media path.
Full parameter-level detail: the cryptographic specification. Disclosure policy and how to report an issue: security.