A reader pointed out a limitation in Why doesn't Signal sign your messages?, where I said Signal signs key material and never messages. That holds right up until a third person joins the conversation. In a group, Signal signs every message.
So why does a third person break it?
What a sender key actually is
Groups do not work the way a two-party conversation does. WhatsApp and Signal use a protocol called Sender Keys, where instead of one group key that evolves over time, every member owns a key of their own and shares it with everyone else.
The structure of that key is the whole post in one line. A sender key is a pair. One half is a public signature key, with a private counterpart the owner keeps. The other half is a symmetric chain key. Sending a message uses both. The sender derives a message key from the chain key, encrypts with it, then hashes the chain key forward so the next message gets a fresh one. That forward ratchet is the symmetric half of the Double Ratchet. Every message then carries the sender's signature, computed with the private half of their sender key. This was documented by Balbás, Collins and Gajland in the first formal analysis of the protocol.
Each member's sender key still has to reach everyone else. That means the chain key and the public signature key, never the private half. Sender Keys assumes a secure channel between every two members of the group to carry them. WhatsApp uses the Double Ratchet for those channels, so the pairwise protocol is still underneath, holding up the group one. That delivery happens once per key, when membership changes. Sending a message to the group then costs one encryption, not one per member, because every recipient decrypts it with the same chain key.
Why a MAC stops working
The last post turned on a single fact about MACs. Alice and Bob hold the same key, so Bob can verify a tag and could equally have created it. A valid tag tells him that either Alice made it or he did, and he knows he did not.
Now hand that key to eleven people. A valid tag says one of twelve made it. Bob rules himself out and is left with eleven candidates, which authenticates nobody.
The obvious repair is a separate MAC key for every pair, which is what Signal does in small groups by running a Double Ratchet session with each other member. It works and it does not scale. A forty-person group means encrypting every message forty times. Sender Keys exists to avoid that cost.
Which leaves signatures. A signature picks out one member from twelve, because only one of them holds the private half. It is the natural fix, and also the one primitive built so that anybody can verify it.
What a group member can prove
Follow that through. A group message carries a signature and a public key that verifies it. Any member can hand both to an outsider, who can check them without trusting the member who supplied them. Bob held a value he could have produced himself, which is why it proved nothing to anyone else. Here he holds one he could not have produced.
The signature proves less than it seems. It verifies against a per-group sender key rather than the long-term identity key, so it shows only that whoever holds that key wrote the message. Tying the key back to a person rests on the word of the member who received it over their private channel, which is testimony rather than proof. Compare DKIM from the last post, where the signing key sits in public DNS under the domain and nobody's word is needed at all. The courtroom caveat still applies too, since anyone holding your unlocked phone has no need of a signature.
A group conversation still leaves behind something a private one does not. In a group of forty, everybody holds transferable evidence about the other thirty-nine.
The papers on Sender Keys do not discuss deniability at all, so this section is my reading of what the mechanism implies rather than a result anyone has proved.
Nobody had checked
Sender Keys protects group conversations for billions of people. Nobody studied it formally in the cryptographic literature until 2022.
There was no specification to study either, so the researchers had to write the protocol description themselves, from a code analysis of Signal's source and WhatsApp's security whitepaper. Their follow-up proves Sender Keys satisfies a weak notion of security, and gathers a set of efficient modifications into a variant they call Sender Keys+.
Just like the last post, where Signal's deniability was assumed for years before anyone proved it, except here it is the whole protocol rather than one property.
The property does not scale
Back to the question. Deniability in a two-party session rests on a key held by exactly two people, and no version of that fact survives a third participant. Nobody chose to drop it. The condition it needed stopped existing, and the signature that replaced it is built to be verifiable by anyone.
MLS, the IETF standard for group messaging, is blunt about this. Members sign their messages with the private key behind their credential, and the architecture document says outright that MLS makes no claims about deniability. Running it deniably might be possible, it adds, but working out what that would require is left to further analysis.
The same section names the flip side. Some services need a recipient to prove to a provider that a given client sent a message, so that abuse can be reported.
Authenticated is not one property, and neither is deniable. Which version you get depends on how many people are in the room.
Sources
- Balbás, Collins and Gajland, Analysis and Improvements of the Sender Keys Protocol for Group Messaging, RECSI 2022
- Balbás, Collins and Gajland, WhatsUpp with Sender Keys? Analysis, Improvements and Security Proofs, 2023
- Beurdouche et al., The Messaging Layer Security (MLS) Architecture, RFC 9750
- Barnes et al., The Messaging Layer Security (MLS) Protocol, RFC 9420
- WhatsApp Security Whitepaper
- libsignal