Missing Context Binding Enables Insider Message Replays in Group Chats

Akshaya Kumar frames group chat encryption as a distinct problem from group key agreement. Secure messaging systems may do sophisticated work to establish and continually refresh shared keys—using mechanisms such as SenderKeys or TreeKEM to pursue forward secrecy and post-compromise security—but that does not by itself establish the properties of messages encrypted under those keys.

In a two-party chat, authenticated symmetric encryption is expected to provide privacy and integrity. In a group, every member holds the same symmetric key. Any member who knows it can therefore construct a ciphertext that appears to come from another member. Privacy and integrity against outsiders are insufficient: the group also needs sender authenticity against insiders.

The proposed abstraction is symmetric signcryption: members share a symmetric encryption key while retaining individual signing-key pairs. The encryption component protects messages from outsiders; the signature is meant to stop one group member from impersonating another.

Kumar draws the threat boundary in deliberately fine-grained terms. An outsider may have compromised users’ long-term signing keys but not the target group’s current symmetric key—the talk’s example is an airport agent who copies keys from a phone before its owner creates a new group with a fresh shared key. An insider belongs to the group and knows its shared symmetric key but lacks other members’ signing keys; this could be a user running a modified client that exposes its own group secrets.

The consequential attacks arise in the latter setting. Access to the group encryption key can be enough to reuse a legitimate signature in a new cryptographic context, even when the attacker never learns the private signing key of the person being impersonated.

The distinction matters where privacy is already unavailable. In discussion, participants pointed to group chats used by protesters or other groups in which an adversary may be able to join. The adversary may see the conversation, but members can still expect it cannot generate a message that appears to come from someone else.

The model does not provide deniability. Kumar said the implementations examined use signatures, making deniability unavailable in this primitive, although follow-up work addresses deniability for symmetric signcryption separately.

A straightforward group-chat construction combines signing and encryption in one of two orders. In sign-then-encrypt, a sender signs a message and encrypts the message-plus-signature under the group key. In encrypt-then-sign, the sender encrypts first and signs the ciphertext. MLS and Session used variants of the former family; Keybase, Signal, and Matrix used variants of the latter.

Neither composition is automatically secure because its ingredients are familiar. Kumar’s central failure mode is a context-switching attack: valid signed material or a valid ciphertext is removed from the context in which it was created and accepted in another.

Consider two people who are both members of group 0 and group 1. An honest sender signs a message and encrypts the resulting message-signature pair under group 0’s key. A malicious group member can decrypt that ciphertext, recover the valid signed material, encrypt it under group 1’s key, and send it there. Recipients see a valid signature from the honest sender, although that sender never sent the message to group 1.

The signature has not become invalid. It is being interpreted under a different encryption context. A group key gives insiders the ability to decrypt and re-encrypt; failing to bind the signature to that key context makes the reuse acceptable to receivers.

The required binding goes in both directions. The signature should authenticate a group-key identifier—a unique value defining the shared encryption key—and, depending on the encryption scheme, the nonce and associated data. The encryption component should bind to a sender identifier that uniquely determines the signing key expected for the message.

Kumar’s team began with a model informed by deployed code, mapped each application’s core chat-encryption algorithm into it, and then either proved security or found an attack. When the model exposed an issue, the researchers examined the surrounding protocol to determine whether it became a practical attack.

Akshaya Kumar describes MLS as a sign-then-encrypt design in which a ratchet tree, key schedule, and secret tree derive fresh message-encryption keys. The relevant point is not the full machinery but the identifier attached to each encryption key: group, epoch, leaf index, and generation.

The group identifies the chat; the epoch identifies the group state; the leaf index identifies the sender’s position in the secret tree; and generation identifies the point in that sender’s ratchet. MLS relies on generation for per-sender loss detection and ordering.

Kumar’s analysis found that the signature authenticates the group, epoch, and leaf index, but not generation. It also does not bind to the encryption nonce. The signature therefore does not fully authenticate the group-key identifier: an insider can move valid signed material between generations, or create a new ciphertext for the same signed plaintext under a different nonce.

That omission permits an insider to take a genuine message-signature pair, decrypt it with a key for one generation, and encrypt it again under a key for another. The signature remains valid because it does not say which generation it belongs to. Recipients can consequently accept the re-encrypted result as a fresh message from the original sender.

Kumar illustrated the attack with a message reading, “I promise to send O $1.” A malicious insider can save the ciphertext, recover the signed contents, and later encrypt those contents under a future generation. The replay does not require server collusion or network control.

Kumar distinguishes this from selective-delivery, or causality, attacks in which a server colluding with an attacker gives different group members different views of a conversation. MLS does not claim to prevent that kind of selective delivery. In the replay case she describes, the insider can act alone; unlike the selective-delivery scenario, comparing transcripts does not reveal a separate conflicting view created by the attacker.

MLS is standardized in RFC 9420. Material Kumar displayed says the protocol does not protect against one group member replaying another member’s PrivateMessage within the same epoch, and advises applications for which replay matters to add mitigations at the application layer.

The replay problem has an ordering counterpart. The desired property, which Kumar calls in-order decryption, is that recipients can decrypt messages and recover their original sending order even when ciphertexts arrive late, out of order, or with some messages dropped.

MLS uses generation as ordering information. But because generation is not authenticated, an insider that obtains two ciphertexts before other recipients can decrypt them can re-encrypt each message under the other’s generation context, and make recipients display them in the opposite order. This needs a stronger attacker position than the basic replay: the attacker needs some ability to intercept or control delivery.

A third MLS issue concerns ciphertext integrity rather than plaintext integrity. The protocol derives an encryption nonce by combining a key-schedule nonce with a random 32-bit reuse guard. Since the signature authenticates neither the nonce nor the values used to derive it, an insider can decrypt a ciphertext and re-encrypt the same signed plaintext under a different nonce.

Kumar characterizes that last consequence as limited: the underlying plaintext does not change, so the attack matters only if an application gives semantic significance to the ciphertext’s bit-level structure.

The fixes follow directly from the missing bindings. At the protocol level, signing generation addresses replay and reordering; signing the nonce, or the key-schedule nonce and reuse guard, addresses the ciphertext-integrity issue. One way to sign generation is to include it in associated data, but Kumar notes that associated data is sent in plaintext and could reveal how many times a user has messaged in a group.

At the application level, Kumar proposed including a monotonically increasing counter in the signed message payload. That gives the application a signed identifier for duplicate detection and ordering.

The researchers disclosed the findings to the MLS working group, received acknowledgement within a couple of hours, and were invited to discuss replay handling at IETF 122. Kumar said the specification was subsequently updated to say it does not protect against insider replay within an epoch and that applications should apply their own mitigations where replay is important. She suggested that it was too late to change the specification or code for that version, and said future protocol versions could potentially be updated.

Kumar attributes part of the analytical gap to scope: much prior MLS work focused on group key agreement rather than chat encryption. But the more important difference is how compromise is modeled.

The earlier model discussed in the talk revealed symmetric and signing keys together when a user was corrupted, then made the attacker passive until the protocol healed. Kumar’s model separates those conditions. It permits an attacker to know a group symmetric key, to know some signing keys, and to try actively to forge for a target user whose signing key remains unknown.

That separation captures the replay condition. The attacker needs the symmetric key to decrypt and re-encrypt a message, but does not need the victim’s signing key because the attacker reuses a signature the victim produced honestly. Treating a participant’s secrets as an all-or-nothing bundle can obscure that attacker.

The discussion noted that version one of the MLS specification reportedly signed generation, but that generation was later removed from signed content during changes to the message structure. Kumar said she could not find an intentional rationale for the omission.

Session had an insider replay issue analogous to MLS: missing binding to the group-key identifier allowed a group member to reuse another participant’s valid signed message. The researchers’ broader review also found that Session did not cryptographically protect against replay generally.

In the LegacyGroups protocol examined, every group ciphertext carried a timestamp used to detect replay, but the timestamp was not authenticated. An outsider could modify it and resend the ciphertext. That outsider would not know the message plaintext, which Kumar said limits the practical sense of the attack unless an insider is involved, but the replay marker itself did not provide cryptographic protection.

The researchers disclosed the issues to Session and learned the service was already deploying GroupsV2 while retiring LegacyGroups. Kumar said the newer version appeared to prevent the reported attacks, while emphasizing that the team had not formally analyzed it.

Keybase posed a different problem. It establishes a group symmetric key and uses it for subsequent messages rather than refreshing the encryption key per message. Its construction is effectively encrypt-then-sign-then-encrypt: encrypt the body under the group key; hash that ciphertext with sender and group-key identifiers and the symmetric key to create a header; sign the header; and encrypt the resulting signature under the same group key.

There is a favorable property: the signature fully authenticates the group-key identifier. But the same symmetric key is part of the signed header and is used to encrypt the resulting signature. The message being encrypted is thus derived from the encryption key itself—a key-dependent message setting in which standard symmetric-encryption guarantees do not automatically apply.

Kumar said the researchers proved security for this particular construction in the random-oracle model, relying on the signing algorithm’s prior hashing of the message. Keybase also reuses the same key for body and header encryption. That can be dangerous because a ciphertext from one context may be transplanted into the other.

The team found no explicit context-separation marker, but the attempted attack failed for an implementation-specific reason. The body plaintext is serialized in MessagePack and always begins with a fixed 17-byte prefix; the header plaintext begins with a signature. The proof depended on signatures being very unlikely to start with the body encoding’s prefix. In this case, non-cryptographic serialization behavior became necessary to the security argument.