Sender-key group messaging can avoid encrypting a separate copy of every ordinary message for every recipient. A sender distributes key material through secure pairwise channels, then uses a sender chain for group messages. That can reduce the sender's repeated upload work, but it does not make the total cost of delivering a message independent of group size.
Separate ordinary message upload, key distribution and server delivery before comparing bandwidth claims.
Three costs hidden inside one “group message”
Consider a simplified group with N members. This is an explanatory model, not a measured Livara benchmark:
| Operation | Pairwise message copies | Sender-key design |
|---|---|---|
| Sender uploads ordinary content | Can require separate encrypted copies for recipients | Can upload one group ciphertext after setup |
| Key establishment or distribution | Pairwise sessions must exist and be maintained | Sender material must reach authorized recipients |
| Relay delivers to the group | Recipients still need their copies | Recipients still need their copies |
| Membership changes | Session and access policy must be updated | Fresh sender material may need redistribution |
“Constant-size sender upload” describes one part of this model. It does not mean constant total network traffic, zero membership-change cost, or identical performance on every device.
The IETF's MLS specification, RFC 9420, discusses the efficiency of sender keys and the extra work required to regain security after compromise. MLS uses a different tree-based approach. The distinction is architectural, not a ranking that makes one design universally best.
Where post-quantum key establishment adds overhead
ML-KEM contributes public-key and encapsulation material that is larger than common elliptic-curve representations. But a protocol need not perform a fresh KEM exchange for every message. Setup, periodic rekeying and ordinary symmetric encryption can have different costs. NIST FIPS 203 defines the ML-KEM parameter sets, not a messenger's complete on-wire format.
That is why multiplying a KEM ciphertext size by “100 users” does not, by itself, predict a 100-member chat's per-message traffic. The answer also depends on session reuse, message framing, recipient devices, retransmission and whether attachments are uploaded once or copied.
A fair comparison states the group and device counts, message and attachment sizes, membership churn, client build and network conditions. Without those details, precise kilobyte or battery figures can mislead.
What Livara says about LGS1
Livara's security page describes LGS1 as a private-group sender-chain design. Each sender's key material is distributed inside pairwise LVR1 sessions; group messages use the resulting chain, and the documentation describes fresh sender keys when members join or leave.
This is the provider's documented architecture, not an independently verified performance result. It supports explaining the intended separation between key distribution and ordinary messages. It does not support a claim that every group upload is exactly 1.1 KB, that the whole system has O(1) delivery cost, or that battery use has been measured as negligible.
Rekeying is part of the security budget
Removing a member from an interface is insufficient if that member still possesses keys capable of decrypting future traffic. A secure transition must exclude removed devices from new key distribution and ensure remaining clients move to the right state. Previously received messages and copied files cannot be cryptographically recalled.
Sender-key forward secrecy and post-compromise recovery also depend on how key chains advance, which secrets are deleted and when fresh material is introduced. They should not be inferred merely from the use of a post-quantum KEM during setup.
Questions for a practical group-chat evaluation
- Does ordinary text upload once per sender or separately per recipient device?
- Which events rotate keys, and what happens while a member is offline?
- How are added devices and removed members represented?
- Are attachments and their decryption keys protected under the same membership rules?
- Which metadata remains visible to the relay?
- Are performance results reproducible on the intended phones and network?
Livara's threat model distinguishes private groups from public channels and documents visible routing information. Public publishing and private-group key distribution should not be combined in a single “encrypted channels” claim.
Sender keys can save repeated work. The useful engineering question is where that work moves, which events make it recur, and how securely the group changes membership.
