End-to-End Encrypted Messaging: Double Ratchet, MLS and Metadata

End-to-end encrypted messaging means only the devices at each end of a conversation hold the keys, so the server that relays messages cannot read them. Modern messengers build this from a key agreement (X3DH or its post-quantum successor PQXDH), a Double Ratchet that changes keys with every message, and for large groups the IETF's Messaging Layer Security (RFC 9420). What it does not hide by default is metadata: who talks to whom, when, from which IP address, and in which groups.

This post goes one level deeper than our end-to-end encryption primer. It opens up the protocols, the post-quantum upgrades, the metadata problem, key verification, and the EU interoperability rules, then ends with a routine you can run today. If you are moving off a big platform altogether, pair it with how to replace Google in your life, how to replace Apple in your life and our private email migration guide.

Key takeaways

• End-to-end encryption protects content. The EFF's Surveillance Self-Defense guide says it "only protects the content of your communication." Metadata, cloud backups and the devices themselves sit outside that promise.
• X3DH (revision 1, 4 November 2016) lets Alice start a conversation while Bob is offline, using prekeys he published in advance. Without comparing keys, its specification says, "the parties receive no cryptographic guarantee as to who they are communicating with."
• PQXDH (revision 3, 24 May 2023) adds a post-quantum KEM to X3DH against "harvest now, decrypt later" recording, but "is not designed to provide protection against active quantum attackers."
• The Double Ratchet gives a fresh key per message (forward secrecy) and heals after a key theft once new Diffie-Hellman outputs flow (post-compromise security). Revision 4 (4 November 2025) adds a Sparse Post-Quantum Ratchet and a Triple Ratchet.
• MLS (RFC 9420, July 2023) serves groups "ranging from two to thousands" with costs that scale with the log of group size. RFC 9750 (April 2025) covers the Delivery and Authentication Services it leaves to applications.
• Sealed sender, private contact discovery, usernames instead of phone numbers, and Tor or proxy routing all reduce metadata. None removes it.
• Article 7 of the Digital Markets Act requires designated gatekeepers to open basic messaging to other providers while preserving "the end-to-end encryption." The IETF MIMI working group is writing the interoperability standards on top of MLS.

What end-to-end encryption protects, and what it leaves exposed

Think of a messenger as four layers: the content of each message, the envelope around it, the devices that hold the keys, and copies made for convenience.

End-to-end encryption covers the first layer: the server stores and forwards ciphertext it cannot open. The EFF contrasts this with transport-layer encryption, which "only protects them as they travel from your device to the app's servers," leaving the service able to read everything in the middle.

The envelope (metadata). A server must know where a message goes. Unless the protocol is designed otherwise, it also learns who sent it, when, from which IP address, its size and its group. The EFF notes metadata "can provide extremely revealing information about you."

The endpoints. Encryption ends where the message is decrypted for display. The Double Ratchet specification warns that a compromise "of device integrity will have a devastating effect on the security of future communications." Spyware reads messages after decryption, whatever the protocol.

Backups and sync. Apple's data security table is a clear example. Under default standard data protection, Messages in iCloud is end-to-end encrypted only "when iCloud Backup is disabled"; with backup on, the backup "includes a copy of the Messages in iCloud encryption key," and backup keys sit in Apple data centres. Advanced Data Protection makes the backup end-to-end encrypted, key included. Check the backup setting as carefully as the messenger.

A short dated history of the protocols

Dates below are taken from the specifications, standards bodies and project posts listed in the sources.

How X3DH starts a conversation with someone who is offline

The hard part of messaging, compared with a web connection, is that the other person is usually not online. TLS can run a fresh handshake because both sides are present. A messenger has to let Alice send Bob an encrypted first message at 1am while Bob's phone is off.

X3DH, short for Extended Triple Diffie-Hellman, solves this with prekeys. The specification describes three parties: Alice, Bob and a server that stores Bob's published keys and holds messages until he collects them.

The keys Bob publishes

Bob uploads a bundle to the server:

• His long term identity key (IK).
• A signed prekey (SPK), which he replaces "at some interval (e.g. once a week, or once a month)," with a signature over it made by his identity key.
• A batch of one-time prekeys (OPK), each meant for a single conversation start. The server hands out one per request and deletes it.

When Alice wants to talk, she fetches the bundle, checks the signature on the signed prekey and aborts if it fails, then creates a fresh ephemeral key (EK) of her own.

The four Diffie-Hellman calculations

Alice computes up to four Diffie-Hellman values and feeds them into a key derivation function to get a 32 byte shared secret:

1. DH1 between her identity key and Bob's signed prekey.
2. DH2 between her ephemeral key and Bob's identity key.
3. DH3 between her ephemeral key and Bob's signed prekey.
4. DH4 between her ephemeral key and one of Bob's one-time prekeys, if the server had one left.

The spec spells out the roles: "DH1 and DH2 provide mutual authentication, while DH3 and DH4 provide forward secrecy." Alice then deletes her ephemeral private key and the intermediate values, and sends Bob her identity key, her ephemeral key, which prekeys she used, and a first ciphertext. Bob repeats the same calculations from his side, deletes the one-time prekey, and both now share the same secret without ever having been online together.

What X3DH does not do for you

Three limits in the specification matter. Authentication is only as good as key verification: the parties "may compare their identity public keys" by fingerprint or QR code, and otherwise the server could hand Alice a key it controls. The server can also weaken forward secrecy without reading anything, by refusing to hand out one-time prekeys so the first message depends on the signed prekey alone; the spec suggests rate limits on fetching bundles. And a first message sent without a one-time prekey can be replayed, which is why the follow-on protocol should agree fresh keys quickly. The Double Ratchet does exactly that.

How PQXDH adds post-quantum protection to the first message

A large enough quantum computer would solve the elliptic curve discrete log problem that X3DH rests on. The specific worry today is recording: someone captures encrypted traffic now and decrypts it later, once the hardware exists. Signal's 2023 post framed PQXDH as protection "against the threat of a quantum computer being built in the future."

PQXDH keeps every X3DH step and adds one more ingredient. Bob also publishes post-quantum KEM keys, each signed with his identity key: a "last-resort post-quantum prekey" that he changes periodically, and a set of signed one-time post-quantum prekeys. Alice encapsulates a secret to that key, sends the ciphertext with her first message, and mixes the encapsulated secret into the key derivation along with the elliptic curve outputs. The specification lists the parameter as a KEM "that has IND-CCA post-quantum security (e.g. Crystals-Kyber-1024)." NIST later standardised that family as ML-KEM in FIPS 203, published on 13 August 2024.

The result is hybrid. An attacker has to break both the elliptic curve exchange and the KEM to recover the session secret. If either holds, the first message stays secret.

The specification is candid about what PQXDH does not cover. It "provides post-quantum forward secrecy" but "still relies on the hardness of the discrete log problem for mutual authentication." Its section on active quantum adversaries explains that a malicious server with a quantum computer could forge Bob's signatures on fake post-quantum prekeys. The reason authentication can stay classical for now is that impersonation has to happen live. A recorded conversation cannot be retroactively impersonated, so the urgent problem was confidentiality, and that is what PQXDH solves.

How the Double Ratchet gives forward secrecy and post-compromise security

X3DH or PQXDH produces one shared secret. The Double Ratchet takes it from there and keeps changing keys for the life of the conversation.

KDF chains

The basic building block is a KDF chain: feed a key and an input into a key derivation function, take part of the output as a message key and the rest as the next chain key. The Double Ratchet specification lists three properties of such a chain, in its own words: resilience, "forward security" (past output keys stay random to someone who learns the current chain key) and "break-in recovery" (future output keys stay random once fresh entropy is added).

Each party keeps three chains: a root chain, a sending chain and a receiving chain. Alice's sending chain mirrors Bob's receiving chain.

The symmetric-key ratchet

Every message advances the sending or receiving chain by one step, producing a unique message key. Because the step is one way, deleting a used message key means nobody, including a future thief of the current chain key, can recompute it. That is per message forward secrecy.

The specification is clear that this half alone does not heal: "The KDF inputs for the sending and receiving chains are constant, so these chains don't provide break-in recovery."

The Diffie-Hellman ratchet

Healing comes from the second ratchet. Each message carries the sender's current ratchet public key. When a party receives a new ratchet key from the other side, it performs a Diffie-Hellman calculation with its own ratchet key, feeds the result into the root chain, and starts a fresh receiving chain. It then generates a new ratchet key pair of its own and starts a fresh sending chain from another root chain step.

So whenever the conversation changes direction, new Diffie-Hellman randomness enters the key schedule. An attacker who stole all of Alice's chain keys on Monday can follow her messages only until the next round trip, because the new Diffie-Hellman output depends on a private key the attacker never saw. That is post-compromise security, and it only works if the attacker was passive. The specification warns that an attacker holding compromised keys could instead substitute their own ratchet keys "via continuous active man-in-the-middle attack." That is one more reason to verify keys.

Out of order messages and MAX_SKIP

Mobile messages arrive late and out of order. Headers carry message numbers so the receiver can store skipped message keys, up to a MAX_SKIP limit set "low enough that a malicious sender can't trigger excessive recipient computation." Stored skipped keys are a small forward secrecy cost, so the spec covers deleting them.

Header encryption

Ratchet headers reveal message numbers and ratchet public keys, which help an observer link messages. The specification's header encryption variant hides them with separate header keys, a small metadata fix inside the protocol.

Post-quantum ratchets: SPQR, the Triple Ratchet and PQ3

PQXDH puts a post-quantum secret into the first key. It does not cover a different attack: someone who compromises a device today, records later traffic and waits for a quantum computer. Revision 4 of the Double Ratchet specification says that against such adversaries "classical Double Ratchet healing provides no protection," because the healing step uses elliptic curve Diffie-Hellman, which that attacker can eventually break.

Why you cannot just swap in ML-KEM

Replacing Diffie-Hellman in the ratchet with a KEM is expensive. Signal's October 2025 post notes that ML-KEM 768 keys and ciphertexts are "over 1000 bytes each," against 32 bytes for ECDH, which would multiply the size of short texts many times over.

The Sparse Post-Quantum Ratchet

SPQR uses a sparse continuous key agreement. Instead of producing a fresh post-quantum secret with every message, the parties advance a post-quantum epoch every so often. The large KEM key and ciphertext are split into chunks with erasure coding and carried a piece at a time on normal messages. Signal's post explains why erasure codes matter: once the receiver has enough chunks, in any order, it can rebuild the whole value, and a middleman cannot block the exchange by dropping one specific chunk.

The Triple Ratchet

The Triple Ratchet runs the classical Double Ratchet and SPQR side by side. Section 6.1 of the specification puts it simply: run both, "but only use them to produce message keys," then combine the two message keys with a KDF into the key that actually encrypts the message. An attacker has to break both to read anything.

Signal's post also explains why naive downgrade on failure breaks when two people are rarely online together, and says conversations will move to the new protocol "without you needing to take any action."

iMessage PQ3

Apple announced PQ3 for iMessage on 21 February 2024, rolling out with iOS 17.4, iPadOS 17.4, macOS 14.4 and watchOS 10.4. According to Apple, each device registers a Kyber (ML-KEM) public key so the first message is protected even if the receiver is offline, and an adaptive post-quantum rekey runs "approximately every 50 messages" and at least once every 7 days. Authentication stays classical, for the reason Signal gives: impersonation has to happen in real time.

What these upgrades change for you

The last row is the one that matters most for most people. No ratchet protects a device that is already controlled by someone else.

How MLS handles large groups, and why it was standardised

Group chats are where pairwise protocols get expensive.

The two older approaches

The simplest group design sends every message over each member's pairwise session, one encryption per recipient. The common optimisation is sender keys: each member distributes a symmetric key over the pairwise channels and encrypts each group message once. RFC 9420 notes the catch: post-compromise security needs "a number of key update messages that scales as the square of the group size," and someone who learns a sender key "can often indefinitely and passively eavesdrop." Matrix's Megolm ratchet is in this family; its specification calls its forward secrecy partial and tells applications to "periodically start a new session."

TreeKEM and epochs

MLS changes the structure. Members sit at the leaves of a binary ratchet tree. Every internal node has a key pair whose private key is known only to the members below it. RFC 9420 calls this the tree invariant, and it makes it possible "to encrypt to all group members except one, with a number of ciphertexts that is logarithmic in the number of group members."

Group history is a sequence of epochs. In each epoch the members share an epoch secret, and everything else (message keys, membership authentication, exporters) derives from it. Changes happen through a small set of messages:

When a member updates its leaf key, it generates new keys for every node on the path from its leaf to the root and encrypts each new secret to the sibling subtree. Everyone in the group can then derive the new root secret, and a removed member, who sits in no subtree that receives the new secrets, cannot.

Worked example 1: the cost of healing a 1,000 member group

Take a group of 1,000 members and suppose every member's keys may have been exposed, so every member needs to refresh.

• Sender keys. Each member generates a new sender key and sends it over a pairwise channel to the other 999 members. That is 1,000 times 999, or 999,000 pairwise encryptions for the whole group to recover. This is the square of the group size the RFC warns about.
• MLS. A full binary tree for 1,000 leaves has a depth of 10, because 2 to the power of 10 is 1,024. One member's update path touches about 10 nodes, so in the best case it produces around 10 encrypted path secrets. If every member commits an update in turn, the total is about 1,000 times 10, or roughly 10,000 encryptions, about one hundredth of the sender key cost.

Real trees are not always full, and blank nodes after removals cost extra ciphertexts, so the MLS figure is a best case. The order of magnitude difference is the point, and it is why the IETF took the problem on.

Cipher suites

RFC 9420 registers seven initial cipher suites. The mandatory one is MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519: X25519 through HPKE (RFC 9180), AES-128-GCM, SHA-256 and Ed25519. Others pair P-256, P-384, P-521 and X448 with matching symmetric choices. None of the initial suites is post-quantum, so check what your library actually negotiates.

Why standardise it

The abstract gives the reason: agreeing a group key "is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time." Before MLS each large messenger had its own group design. A shared, analysed protocol gives implementers a common base and, as the MIMI section shows, makes interoperability between services possible.

What MLS leaves to the application

RFC 9750 splits the system into clients, a Delivery Service (DS) that stores and forwards messages, and an Authentication Service (AS) that binds credentials to identities; MLS does not say how to run either. The DS needs only an opaque group ID, the epoch and the message type, but even that, "when correlated with other data," can reveal sensitive information. The RFC recommends TLS or QUIC transport, encrypting stored metadata such as push tokens at rest, and MASQUE, Tor or a VPN where anonymity matters.

What leaks as metadata, and which techniques reduce it

Metadata is the part of messaging privacy that protocols handle least well, because servers need some of it to work. Here is what leaks, and how projects have tried to cut it down.

Contacts and contact discovery

To show you which contacts use a messenger, the app has to compare your address book with the user list. The old shortcut was hashing phone numbers. Signal's 2017 post describes exactly that and says "the hash of a user identifier can almost always be inverted."

Worked example 2: why hashed phone numbers are not private

A national numbering plan with ten digit numbers has at most 10 to the power of 10, or 10 billion, possible numbers. Suppose an attacker can compute 100 million SHA-256 hashes per second. Hashing every possible number then takes 10 billion divided by 100 million, or 100 seconds. Truncating the hash, as Signal's old design did, does not help: the server can still match each truncated hash to the few numbers that produce it. A hash of a small input space is a lookup table, not anonymity.

Signal's 2017 answer was private contact discovery inside an Intel SGX enclave with remote attestation, so that clients could check which code was processing their address book. That shifts trust from the operator to the enclave hardware and the published code; it does not remove trust.

Who is messaging whom: sealed sender

A normal message submission authenticates the sender to the server, which then knows both ends. Signal's sealed sender preview, from 29 October 2018, moves the sender's identity inside the encrypted envelope. The recipient's client checks a short lived sender certificate, issued by the service, containing the sender's phone number, identity key and an expiry. To limit abuse, the sender must prove knowledge of a 96 bit delivery token derived from the recipient's profile key, which is only shared with contacts and approved conversations. Sealed sender hides the "from" field from the service at delivery time. It does not hide your IP address, and a service that wanted to correlate connection timing could still try.

Phone numbers as identity: usernames

Phone numbers are durable identifiers tied to a SIM and often a legal name. On 20 February 2024 Signal stopped showing phone numbers to everyone by default and added usernames, though registration still needs a number. Signal's post says usernames are protected with a Ristretto 25519 hashing scheme and zero-knowledge proofs, so the service "can't easily see or produce the username if given the phone number." If someone hands Signal a username known to be in use, it can link that username to the current account.

IP address and network position

Every connection exposes an IP address to the server and to your network. End-to-end encryption does nothing about this. Options are a VPN (which moves trust to the VPN operator), Tor (which spreads it across relays so no single one sees both ends) or an application level relay. RFC 9750 lists MASQUE proxies, Tor and VPNs as ways to improve metadata protection.

Group membership, timing and size

In sender key designs the server often knows the member list because it fans messages out. MLS reduces the routing header to an opaque group ID and epoch, though a Delivery Service can usually still see which clients fetch a group's messages. Signal says its groups use "zero-knowledge technology" to avoid revealing membership. Size, timing and frequency stay visible to anyone who sees ciphertext pass; few consumer messengers pad or batch traffic.

Peer to peer and onion routed designs

Peer to peer designs remove the central operator, but expose each peer's IP address to the others unless traffic goes through onion services, and they make offline delivery harder because there is nowhere for a message to wait.

Key verification, safety numbers and key transparency

If the server hands out a fake identity key, every protocol above works perfectly while encrypting to an impostor. Verification closes that gap.

Safety numbers

Signal calls its fingerprint a safety number. Its November 2016 post explains the design: one number per conversation rather than two separate fingerprints, a numeric encoding because "all supported languages have a representation for base-10 digits," and 12 groups of 5 digits, 60 digits in all. You compare the number in person or over another trusted channel, or scan the QR code. The same post records a lesson from real use: people posted screenshots of QR codes publicly, which leaked the phone numbers embedded in them, so the QR code was changed to contain only the safety number.

Worked example 3: how strong is a 60 digit safety number?

One decimal digit carries log2(10), about 3.32 bits, so each 30 digit half of the safety number carries about 99.7 bits and the full 60 digits about 199. Faking one half means finding a key whose fingerprint matches all 30 digits, on the order of 2 to the power of 99 attempts, far beyond practical reach. The weakness is not the number; it is that most people never compare it.

Why people skip verification

Verification asks people to meet, or trust a second channel, for something with no visible effect when it succeeds. Safety numbers also change whenever a contact reinstalls or changes phone, so warnings are common and mostly benign, which trains people to tap through them. Signal still encourages "comparing safety numbers (ideally in person)."

Apple Contact Key Verification

Apple's iMessage Contact Key Verification automatically checks that you are messaging the intended person and alerts you if verification fails. You can also compare a code in Conversation Details or use a shareable Public Verification Code. It needs iOS 17.2, macOS 14.2 or the matching later releases on every signed in device, iCloud Keychain and two factor authentication. Apple notes it "isn't designed to prevent fraud such as phishing."

Key transparency

Key transparency tries to make verification automatic. The service publishes every identity to key binding into an append only, publicly auditable data structure. Clients check that the key they were given for a contact is the one in the log and that their own entry has not been changed behind their back. If the server hands one user a different key than the log shows, it gets caught.

WhatsApp described its deployment on 13 April 2023: an automatic check that "requires no additional actions or steps from users," backed by an open source library called Auditable Key Directory that lets anyone verify audit proofs. At the IETF, the KEYTRANS working group is standardising the approach. Its charter starts from the problem that keys "are often authenticated solely by the assertion of the communications service provider" and lists four requirements: transparent, user friendly, private and efficient. As of 7 October 2026 its architecture document, draft revision 10, was submitted to the IESG for publication as Informational, and the protocol draft is at revision 5.

The Digital Markets Act and the IETF MIMI work

What Article 7 requires

Regulation (EU) 2022/1925, the Digital Markets Act, was adopted on 14 September 2022. Article 7 covers "number-independent interpersonal communications services," which in practice means internet messengers rather than SMS. When such a service is listed in a gatekeeper's designation decision, the gatekeeper must make basic functions interoperable with other providers "upon request, and free of charge," on this schedule:

The security line is in paragraph 3: "The level of security, including the end-to-end encryption, where applicable, that the gatekeeper provides to its own end users shall be preserved across the interoperable services." The gatekeeper must publish a reference offer with technical details, must meet a reasonable request within 3 months, may only share personal data that is "strictly necessary," and may take measures to protect "integrity, security and privacy" that are strictly necessary and proportionate. Users stay free to decide whether to use interoperable features at all. Article 3(10) gives gatekeepers 6 months from listing to comply.

On 6 September 2023 the European Commission designated its first six gatekeepers. The Commission's current gatekeeper page lists WhatsApp and Messenger among Meta's designated core platform services, both under case DMA.100024. Apple's listed services on that page are the App Store, iOS, iPadOS and Safari; iMessage is not among them.

How one gatekeeper described its approach

Meta's engineering post of 6 March 2024 says WhatsApp and Messenger both build on the Signal Protocol and that Meta would "prefer third-party providers to use the Signal Protocol." Third party clients authenticate with OpenID and a JSON Web Token over WhatsApp's Noise Protocol transport and host their own media. The post also notes that Meta's end-to-end promise depends on controlling both clients; with a third party client, the conversation also depends on that client.

What the IETF MIMI working group is building

The More Instant Messaging Interoperability (MIMI) working group, in the IETF Applications and Real-Time Area, is specifying "the minimal set of mechanisms required to make modern Internet messaging services interoperable." Its charter assumes MLS for key establishment and says the standards must let services interoperate "without undermining the security guarantees that they provide." The work covers a transport and delivery protocol between providers (needed because MLS requires handshake messages to be ordered), a common content format, identity building blocks such as X.509 certificates or verifiable credentials, room policy, and discovery of which service a user is on.

Out of scope, per the charter: spam and abuse metadata processing, cross service moderation, MLS extensions, new identity formats, and lookup services "that reveal the list of messaging services associated with a given user identity without the user's permission."

As of October 2026 the active drafts are the architecture (03), content format (09), protocol over HTTPS and MLS (06) and room policy (04). The charter's IESG milestones were dated 2025, so the work is behind schedule and none is an RFC yet.

What this means in practice

Interoperability changes the trust model. You also trust the other provider's client, key distribution and metadata handling. Content encryption can be preserved across the boundary, as Article 7 requires, while metadata exposure grows because two operators see the envelope. Opting in stays your choice.

Choosing a messenger by category

This table compares categories of messaging systems, not products. It is not a ranking. Within each category, individual apps vary, so check each project's own documentation for its current defaults.

The decisive questions are the default, the identifier you must share, whether backups are end-to-end encrypted with a key you hold, and whether the client code is public.

Step by step: verify, lock down and check

These steps work in most end-to-end encrypted messengers, though menu names differ. Where a project documents a specific path, it is quoted.

Step 1: pick by category, then read the security page

Write your threat model in one line ("my employer manages my laptop"), pick a category from the table, then check the app's own documentation for three facts: end-to-end encryption by default for every chat including groups, a way to hide your phone number, and how backups are protected.

Step 2: verify the contacts who matter

1. Open the conversation and find the safety number, security code or verification option.
2. Compare it in person by scanning the QR code, or read it over a call where you recognise the voice.
3. Mark the contact as verified if the app supports it.
4. If you use iMessage, turn on Contact Key Verification on every device (it needs iOS 17.2, iPadOS 17.2, watchOS 10.2, macOS 14.2 or visionOS 1.1 or later) and verify key contacts with the on device comparison.
5. When a safety number changes, confirm through another channel before sending anything sensitive.

Step 3: lock down backups

1. Find out where your messages are backed up: on device, to the app's own encrypted backup, or to the phone platform's cloud.
2. If the platform cloud is involved, check whether the backup is end-to-end encrypted. On Apple devices, standard data protection keeps backup keys in Apple data centres and puts a copy of the Messages in iCloud key in your backup; Advanced Data Protection makes the backup end-to-end encrypted.
3. If the app offers its own encrypted backup, store the recovery key offline. Signal's secure backups use a 64 character recovery key generated on the device and "never shared with Signal's servers"; losing it means losing the backup.
4. If you do not need history on a new phone, consider no cloud backup at all.

Step 4: check linked devices

Every linked desktop or tablet is another endpoint that holds keys.

1. Open the app's linked devices list.
2. Remove anything you do not recognise or no longer use, including old work laptops.
3. Repeat monthly, and immediately after losing a device.

On Matrix, each session is a device with its own keys, and the client-server API lists them (replace the homeserver; read -s keeps the token out of shell history):

# List your devices (sessions) on a Matrix homeserver
read -rs MATRIX_TOKEN
curl -s -H "Authorization: Bearer $MATRIX_TOKEN" \
  https://matrix.example.org/_matrix/client/v3/devices | jq '.devices[] | {device_id, display_name, last_seen_ts}'

Removing a device uses DELETE /_matrix/client/v3/devices/{deviceId}, which uses User-Interactive Authentication, so most people do it from their client's session list. Then use cross-signing so remaining devices are verified once, not pair by pair.

Step 5: reduce what your account reveals

1. Hide your phone number if the app supports it, and share a username, link or QR code instead.
2. Turn off read receipts and typing indicators if timing is sensitive.
3. Set disappearing messages for chats that do not need history.
4. If your IP address matters, route the app through Tor or a VPN you trust, and accept that this shifts rather than removes trust.

Step 6 (for builders): know which crypto libraries you ship

A protocol is only as good as the library version you ship. Check your dependency tree:

# Node.js: which libsignal and Matrix SDK versions are installed?
npm ls @signalapp/libsignal-client matrix-js-sdk

# Rust: which crates pull in an MLS implementation?
cargo tree -i openmls

# Generate an inventory you can track over time
safeguard scan --dir .

@signalapp/libsignal-client is published by Signal under AGPL-3.0, matrix-js-sdk is the Matrix JavaScript SDK, and openmls is a Rust implementation of MLS. Version numbers move quickly, so pin them in a lockfile and review upgrades like any other security relevant change.

Common mistakes

• Treating "encrypted" as "end-to-end encrypted." If the documentation does not say end-to-end, assume the operator can read content.
• Forgetting the backup. Chats copied into a cloud backup under the provider's key are only as private as that backup.
• Never verifying anyone, or tapping through safety number changes. Most changes are reinstalls; the one that is not is the one that matters.
• Leaving old devices linked. A forgotten desktop session is a live endpoint with keys.
• Assuming groups match one to one chats. Sender key designs heal slowly and the server may know the member list.
• Assuming post-quantum means spyware proof. Hybrid ratchets do nothing about a compromised phone.
• Using a hashed phone number as an anonymous ID. As worked example 2 shows, it can be reversed in minutes.
• Building on MLS without designing the Delivery and Authentication Services. RFC 9750 exists because MLS leaves those to you.

FAQ

Can the messaging company read my end-to-end encrypted messages?

Not through the protocol: the server stores only ciphertext. It still sees metadata, could hand out a false key if you never verify contacts, and may hold readable copies if your cloud backup is not end-to-end encrypted.

What is the difference between the Signal Protocol and MLS?

The Signal Protocol (X3DH or PQXDH plus the Double Ratchet) is built for two party sessions, with groups made from pairwise sessions or sender keys. MLS (RFC 9420) is an IETF standard for groups from two to thousands, with logarithmic update costs.

What is forward secrecy in messaging?

Stealing today's keys does not decrypt messages already sent and deleted. The Double Ratchet derives a new key per message and deletes it after use.

What is post-compromise security?

A conversation becomes safe again after a passive attacker stole keys, once fresh randomness enters the key schedule: each Diffie-Hellman ratchet step in the Double Ratchet, each committed update in MLS.

Are encrypted messengers quantum safe?

Partly, depending on app and version. PQXDH protects the first message; hybrid ratchets such as the Triple Ratchet and PQ3 extend that through the conversation. Authentication remains classical.

What is sealed sender?

A Signal technique from 2018 that hides the sender's identity from the service at delivery, using a delivery token to limit abuse. It does not hide your IP address.

What is a safety number and should I check it?

A 60 digit value derived from both identity keys. If it matches on both phones, no key was substituted. Check it for contacts who matter, and again when it changes.

What does key transparency do?

It publishes identity keys in an auditable log so apps can detect a server showing different keys to different people. WhatsApp deployed one in 2023; the IETF KEYTRANS group is standardising it.

Will the Digital Markets Act let me message a WhatsApp user from another app?

Only if another provider requests and builds interoperability under Article 7, and you opt in. WhatsApp is a designated service, and end-to-end encryption must be preserved.

Where Safeguard fits

Safeguard does not encrypt messages, verify contacts, audit protocol designs or protect phones, so its role here is indirect: it serves teams who build messaging features on open source cryptography libraries. The CLI scans a repository, container image or SBOM file (safeguard scan --dir ., --image <name>, --sbom <file>), the platform shows which projects contain a given component version, findings are matched against vulnerability databases with reachability analysis, and policies and gates can stop a known vulnerable version from shipping. It cannot judge protocol design or fix the endpoint problems above.

A messaging client is a thick stack of open source code: protocol libraries, media codecs, push and transport layers, and the build tooling that assembles them. The guarantees in this post hold only if the code that implements them is current, so the hygiene below applies to anyone who builds or self hosts messaging software.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, open the interactive terminal and ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with your approval and pushes nothing. The same flow applies when a messaging backend or client build pulls in an outdated crypto or transport library: ask, review each step, test, then decide.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and runs a scan from the terminal. That suits teams who self host a federated messaging server or build clients and want dependency scans to run locally rather than handing repository access to a hosted service.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude may use. If your team already asks an assistant questions such as "which services ship this version of our messaging SDK," this is how to give it scoped access to that inventory.

Click through it at your own pace, or open it full screen.

Download the apps at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• Signal: The X3DH Key Agreement Protocol, revision 1, 4 November 2016
• Signal: The PQXDH Key Agreement Protocol, revision 3
• Signal: The Double Ratchet Algorithm, revision 4, 4 November 2025
• Signal: XEdDSA and VXEdDSA signature schemes
• Signal: Specifications index
• Signal blog: Quantum Resistance and the Signal Protocol, 19 September 2023
• Signal blog: Signal Protocol and Post-Quantum Ratchets, 2 October 2025
• Signal blog: Technology preview: Sealed sender for Signal, 29 October 2018
• Signal blog: Technology preview: Private contact discovery for Signal, 26 September 2017
• Signal blog: Safety number updates, 17 November 2016
• Signal blog: Keep your phone number private with Signal usernames, 20 February 2024
• Signal blog: Introducing Signal Secure Backups, 8 September 2025
• RFC 9420: The Messaging Layer Security (MLS) Protocol, July 2023
• RFC 9750: The Messaging Layer Security (MLS) Architecture, April 2025
• RFC 9180: Hybrid Public Key Encryption, February 2022
• IETF Datatracker: More Instant Messaging Interoperability (mimi) working group charter
• IETF Datatracker: MIMI working group documents
• IETF Datatracker: Key Transparency (keytrans) working group charter
• IETF Datatracker: KEYTRANS working group documents
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, 13 August 2024
• Regulation (EU) 2022/1925 (Digital Markets Act), Official Journal L 265, 12 October 2022
• European Commission: Digital Markets Act, gatekeepers and designated core platform services
• European Commission press release IP/23/4328: Commission designates six gatekeepers, 6 September 2023
• Apple Security Research: iMessage with PQ3, 21 February 2024
• Apple Support: About iMessage Contact Key Verification
• Apple Support: iCloud data security overview
• Engineering at Meta: Deploying key transparency at WhatsApp, 13 April 2023
• Engineering at Meta: Making messaging interoperability with third parties safe for users in Europe, 6 March 2024
• Matrix Specification: Client-Server API (devices, cross-signing, key backup)
• Matrix Specification: Olm, a cryptographic ratchet
• Matrix Specification: Megolm group ratchet
• EFF Surveillance Self-Defense: Communicating with Others
• Tor Project support: About Tor
• npm registry: @signalapp/libsignal-client
• crates.io: openmls

Last reviewed: 23 October 2026. Messaging apps change defaults and protocol versions often, and the MIMI and KEYTRANS drafts are still moving; check the linked specifications and each app's own documentation for current behaviour.