Compare the cost of a defined operation and the evidence for a defined threat—not just a tree diagram against a sender-key diagram.
Messaging Layer Security (MLS) and Livara's LGS1 are not two interchangeable certificates of group-chat safety. MLS is an IETF protocol standard; LGS1 is Livara's documented product-specific design. Comparing them fairly means separating architecture, implementation evidence and the behavior users actually experience.
The key distinction is tree-based shared group state versus sender keys distributed through pairwise sessions. Neither label alone tells you whether a particular application handles a removed member, stale device or compromised key correctly.
The architectural difference
RFC 9420 specifies MLS for asynchronous group key establishment. It uses a ratchet tree and group epochs, with forward secrecy and post-compromise security under stated conditions. Its tree structure reduces certain key-update costs as group size grows.
Livara's security documentation describes LGS1 as a signed sender chain for each member, distributed through LVR1 pairwise sessions and rotated on membership changes. This is a product claim, not evidence that LGS1 conforms to MLS or has the same analysis.
| Question | MLS | Livara LGS1 documentation |
|---|---|---|
| Shared structure | Ratchet tree and epochs | Per-sender chains |
| Key updates | Group state changes committed into a new epoch | Fresh sender keys distributed to members |
| Specification status | IETF standard, RFC9420 | Product-specific published description |
| What still needs evaluation | Application integration and implementation | Complete specification, implementation and independent evidence |
This table describes design categories. It is not a benchmark or a security ranking.
What “logarithmic” does—and does not—mean
A cryptographic update can use a logarithmic number of encrypted tree-path components without making all work in the system logarithmic. Messages still need distribution, clients keep state, and behavior depends on group structure and operations. The old comparison “MLS needs O(log N) messages while everything in LGS1 is faster” mixed different costs and offered no measurements.
The MLS architecture, RFC 9750, treats the delivery service separately from cryptographic key establishment. It discusses message distribution and ordering of group changes. That separation matters: client computation, bytes in a commit, total server fanout and reconnect traffic are different metrics.
A meaningful performance report should state:
- group size and number of devices per person;
- whether the operation is a normal message, member removal, key update or reconnect;
- bytes sent by the initiating client versus total delivery traffic;
- elapsed time, device model, implementation version and network conditions;
- the cost of missed updates and repeated membership changes.
Without those details, claims of “milliseconds,” “low state overhead” or superiority at a particular group size are not established.
Removing a member is a lifecycle test
An administrator removing an account is only one part of the security story. Clients must agree on the new membership state, use suitable fresh keys and avoid giving those keys to excluded devices. A person already holding old plaintext or old keys may retain access to old content; removal cannot make their copies disappear.
For either system, a useful test asks: after removal completes, can the removed device decrypt a new non-sensitive test message? Does a member who was offline catch up safely? Are all devices belonging to an account handled? Does the interface make failures or membership changes visible?
These are proposed evaluation questions, not results from tests conducted here. A product comparison should publish the observed outcome and test version rather than equate a successful admin click with cryptographic exclusion.
Forward secrecy and recovery are conditional
Keeping old messages protected after later compromise depends on retiring old secret material. Recovering protection for future messages depends on incorporating fresh secrets after the attacker loses the relevant access. In MLS, processing group updates is part of that recovery story; merely sending an update is not the same as every member having applied it. See the security considerations in RFC 9420.
For a sender-key design, ask how each sender's compromised state is replaced and redistributed. A one-way chain alone should not be described as automatically healing from an attacker who knows its current state. Pairwise protection used during redistribution is relevant, but does not replace a complete group-level analysis.
Post-quantum claims need a specific cipher suite and scope
The cipher suites defined in the base RFC9420 use classical public-key mechanisms. MLS is extensible, so a claim about a particular implementation should identify its actual suite and extensions rather than declare all MLS deployments permanently classical.
LGS1's documented use of hybrid LVR1 distribution is a different claim from an independently analyzed post-quantum guarantee for every group operation. FIPS 203 standardizes ML-KEM; it does not certify the complete group protocol that incorporates it. Evaluate authentication, membership changes, key compromise and implementation together, not just the KEM name.
What to request before making a product decision
Ask for the current protocol specification, test vectors and release-specific independent review, including unresolved findings. Then compare ordinary product requirements: supported devices, update behavior, recovery, moderation roles and data retained by servers.
The MLS architecture explicitly considers application services and their trust assumptions. Similarly, Livara's threat model should be read alongside its product claims. Encryption does not make authorized participants trustworthy, stop screenshots or remove every form of metadata.
If evidence is missing, record “not established” rather than automatically labeling a design insecure or superior. The decision should reflect your group’s risks and the quality of available evidence.
Frequently asked questions
Is LGS1 an implementation of MLS?
The published descriptions show different architectures. This article does not identify LGS1 as an MLS implementation or claim interoperability.
Does MLS require every member to be online at once?
No. Asynchronous use is part of its design. Applications still need policies for delayed updates, stale state and long-offline members.
Does post-quantum key distribution settle group security?
No. It addresses part of key establishment. Identity, membership, key lifecycle, endpoint security and implementation still require evidence.
Which design is faster?
There is no benchmark in this article establishing a winner. Measure the operations and deployment that matter to your group.
