"End-to-end encrypted" gets used loosely enough that it's worth being precise about what SimXmil actually does under the hood. The short version: every single message you send gets its own, unique encryption key, derived through a construction called the Double Ratchet. Here's what that means and why it matters.

The starting point: a shared secret

When two people start a conversation, their devices perform an ECDH (Elliptic-Curve Diffie-Hellman) key exchange on curve P-256. Each side combines their own private key with the other person's public key to arrive at the same shared secret — without that secret ever crossing the network. This shared secret becomes the root key that seeds everything that follows.

Two ratchets, not one

From the root key, SimXmil runs two linked ratchets:

  • The DH ratchet — every time the conversation "turns" (someone replies), both sides generate a fresh ephemeral key pair and perform a new ECDH exchange, mixing a new Diffie-Hellman output into the root key.
  • The symmetric-key (chain) ratchet — within a single turn, each message advances a one-way KDF chain, so consecutive messages from the same sender still get distinct keys even before the next DH turn happens.

The actual derivation

Simplifying slightly, each step looks like this:

RK, CK = KDF_RK(RK, DH(dh_self, dh_remote))

CK, MK = KDF_CK(CK)

Where RK is the root key, CK is a chain key, MK is the one-time message key actually used to seal a given message, and KDF_RK / KDF_CK are HMAC-based key-derivation steps. The output MK is then used to encrypt the message body with AES-256-GCM, which authenticates the ciphertext as well as encrypting it — a receiver knows immediately if a message was tampered with in transit.

Why this specific construction matters

The one-way nature of the KDF chain is the whole point: it's computationally infeasible to run KDF_CK backwards. So if a single message key MK is somehow compromised, an attacker gains nothing about any earlier message (forward secrecy) and, once the next DH ratchet turn happens, nothing about future messages either (post-compromise / future secrecy). Compromising today's session doesn't unlock yesterday's conversation or tomorrow's.

Groups work differently — on purpose

A group chat can't run a pairwise DH ratchet between every member for every message; it wouldn't scale. Instead, SimXmil gives each group member their own sender key — a chain key they alone advance — and distributes it to other members individually, wrapped through each member's existing 1:1 encrypted session. When someone leaves a group, their sender key is retired and a new one is distributed to remaining members, so a removed member can't decrypt anything sent afterward.

What this buys you in practice

No server-side plaintext, ever — the server only relays ciphertext and never holds a key capable of decrypting it. Private keys are generated and held in non-extractable, device-native secure storage. And because keys rotate per message rather than per session, the practical blast radius of any single compromised key is exactly one message.

For the full picture — including how backups, key verification, and device transfer fit around this — see the full encryption docs. For everything else the app ships beyond messaging, see Features.