Encryption says which keys open a message; we must separately check who received those keys.
No; group end-to-end encryption alone does not prevent a hidden member. The answer to “Can the server add a group member?” depends on membership and member-verification mechanisms, not just message encryption. According to Livara’s documentation, LGS1 encrypts content in compatible private groups that are actually operating in E2EE mode. Key rotation after membership changes is designed to limit future access, and membership and key updates must take effect on devices; it does not take back copies already received.
Key points
- End-to-end encryption targets message confidentiality, but securing the group membership list requires a separate mechanism.
- In a compatible Livara private group whose E2EE status has been confirmed, LGS1 covers messages, edits and attachment keys; do not extend this claim to incompatible older groups.
- Comparing Signal, WhatsApp, SimpleX and Element solely by an “encrypted” label is insufficient; membership-change notifications, administrator roles and identity-verification methods also matter.
- The interface cannot detect every authorized account controlled by an attacker under all conditions; members must check identities and sensitive changes through an independent route.
- Livara Proof Lab provides a local demonstration of P-256, HKDF and AES-GCM and file-hash checking; it is not a full implementation or independent audit of LVR1/LGS1.
Does group encryption prevent hidden members?
No, unless the protocol also coordinates membership state cryptographically and verifiably among members, alongside content. In this article, a “hidden member” means an account with access to future messages whose arrival the human members did not notice or whose identity they did not correctly recognize.
End-to-end encryption means that only the conversation participants’ devices should be able to read message content; but those devices also need to know whom they are sending keys to. If the server can change the recipient list, encryption can work correctly while also encrypting a message for an unwanted member. For the distinction between content and metadata, see the guide to end-to-end encryption and its limits.
A “server attack on an encrypted group” therefore does not necessarily mean breaking AES or solving a mathematical problem. Through membership control, a server might add a valid account to the set of future recipients. Past messages whose keys that account did not possess are a separate matter; the main risk is access after joining.
What do we know about Livara group membership?
Livara’s security documentation distinguishes server control of membership and roles from content encryption. This is an important boundary for evaluation, but does not alone prove a successful practical attack or an entirely invisible entry. Such a claim requires testing client behavior, key distribution, membership-change notifications and attack conditions.
The right question is: do devices independently validate changes to the list, and what is shown to the user before a key is sent to a new member? This article does not present audit or penetration-test results for Livara.
How does membership-list security differ across five messengers?
The key differences are who authorizes membership changes, how members learn about them and whether they can independently verify a new account’s identity. End-to-end encryption alone does not fully answer the question of server trust in a messenger.
| Messenger | Group content | Membership and practical trust | Cautious conclusion |
|---|---|---|---|
| Livara | In a compatible private group with E2EE, LGS1 covers text, edits and attachment keys. | Sender keys are automatically regenerated and redistributed when membership changes. | According to product documentation, compatible private-group content and media keys are protected before delivery; check the status of that particular group. |
| Signal | Signal’s group support documentation says the service does not record group membership, title, image or attributes. | The same source says an administrator can determine who can add members and enable administrator approval for group links; members must still notice membership changes. | The design limits what the service knows, but users must check membership changes and account identities. |
| The WhatsApp Encryption Overview says personal and group messages are end-to-end encrypted. | The WhatsApp help resource describes optional sharing of part of the history with a new member and administrators’ ability to restrict that sharing. | Group content is encrypted, but membership correctness must be assessed through administrator controls and app notifications. | |
| SimpleX | SimpleX group documentation says each member has a separate connection to other members. | The protocol specification describes groups as a set of connections between members with roles and membership-change messages; this does not rule out a human administrator. | A group without a global identifier does not eliminate every membership risk or compromised-device risk. |
| Element / Matrix | The Matrix end-to-end encryption specification defines the m.room.encryption event and room-encryption algorithms. |
The Matrix membership specification models membership through m.room.member events in room state, which homeservers distribute. |
Room encryption and membership state are separate layers; members must check devices and room changes. |
This table is not an absolute ranking. Each system has a different threat model, and the app, device, group administration and member behavior can alter the outcome. For a practical choice, use the 12-question secure-messenger checklist alongside each product’s official documents.
How should we compare server trust in messengers?
Do not reduce trust to a yes-or-no label; ask precisely what the server can see and change. A server that cannot read text may still control communication timing, group membership or initial-key distribution.
First, separate content confidentiality
Check exactly where messages, edits, reactions, titles, attachments and attachment keys are encrypted. According to Livara’s documentation, LGS1 covers text, edits and attachment keys in compatible private groups with E2EE; this claim does not include channels.
Second, identify the membership authority
Determine who can invite members, who approves requests and how the client displays changes. If the server imposes group state, server compromise must be explicitly included in the threat model.
Third, distinguish identity from membership
A familiar name does not prove that a key belongs to that person. In Livara, the safety number allows key fingerprints to be compared outside the app; having this tool does not by itself mean that the entire group membership list has been checked. Attribute key-transparency features to a product only when documented, too.
Fourth, distinguish evidence from claims
Product documentation, audit reports and independent tests are not the same. A reliable report should specify the version, scope, findings and fixes. An algorithm’s name or agreement between two implementations does not alone establish the security of membership management.
How can group-chat members be verified?
Members should promptly check changes to the list and verify the identities of sensitive contacts through an independent channel. For high-risk conversations, merely seeing a name, photo or account number is insufficient: these signs can be mistaken, recycled or controlled by an attacker.
In Livara, two people can compare their safety number in person, in a known call or through an independent route. This can reveal an unexpected key change; however, pairwise comparison does not by itself cover every member of a large group at once. The guide to verifying chats with a safety number explains the practical steps.
For sensitive groups, this short procedure is useful:
- Restrict the ability to add members to administrators as far as possible.
- Check every notification of joining, leaving or role changes as it happens.
- Verify a new member’s identity outside that same group.
- After a suspicious change, stop sending sensitive information and create a fresh group with verified members.
- Periodically review each account’s linked devices and sessions.
These steps reduce risk but do not repair a membership-architecture flaw. If the server or administrator account is compromised and the interface does not show changes clearly, a user may still fail to notice an entry.
Frequently asked questions
Can a server add a group member without breaking encryption?
Yes, if the messenger’s architecture gives the server control of the membership list. In that case the server need not break the cipher; it can add an account to future recipients so clients also encrypt messages for that account. Whether and how this is possible depends on each product’s membership protocol.
How does LGS1 work in Livara groups?
According to product documentation, in compatible private groups with E2EE, LGS1 uses a key chain and sender signatures to protect content and attachment keys. Limiting future access after a member leaves depends on applying the membership change and distributing new keys. Proof Lab only provides local demonstrations of a few cryptographic components and hash checking; this is not a full LGS1 implementation, a protocol audit or proof of secure membership management.
Does comparing safety numbers establish that a hidden member has joined?
No. Comparing safety numbers checks key identity between two people through an independent route and can reveal an unexpected key change. But it does not prove that no other member has entered the group; members must separately check the list, membership notifications and sensitive accounts’ identities.
Which messenger has the most secure membership list?
These sources do not establish an absolute winner, because Signal, WhatsApp, SimpleX, Element and Livara have different membership and threat models. The right choice depends on your risks: check who controls membership, how changes are announced and whether members’ identities can be checked independently of the server.
