I'm still of the opinion that encrypted private group chats are an impossible UX problem (1:1 chat is fine). But if I were to trust anyone to find a way to do it properly, it would be Signal.
Sure, it takes N^2+N messages, but that's not exactly a massive overhead for text. Multimedia takes N times as much bandwidth as the 1-server, server-many model for the sender, but otherwise isn't terrible.
There is actually a way to do it, if you assume PKI (which signal provides) and that all messages will be delivered in some bounded time. It’s called the dolev-strong protocol and it guarantees that all honest members of the group will agree with each other. Unfortunately, it requires one round per group member and delivering all messages within a bounded time isn’t easy.
Which lets you know that Alice and Bob are in contention, which is probably good enough for most situations. "One of these three (or more if you have multiple groups of bad faith actors) sets of users are operating in bad faith" should be plenty of information for a user to make an informed decision. Even if that decision is "wow, how did I end up in a group containing multiple groups of bad actors, I should be elsewhere".
Consensus protocols are tricky, BTW.
A bad actor could screw with you in this naive implementation though
IIUC this is what iMessage does (at least when Messages in iCloud or whatever it's called is disabled), except s/people/devices: say you have three devices and someone sends you one message, the message is encrypted once per recipient device, and three encrypted messages get sent. Whether it's 1 person with 3 devices, 3 people each with 1 device, or 2 persons with one having 2 devices and the other a single one becomes largely immaterial.
In other words, it has a bad UX. Which was the original point about encrypted group chats.
If one app found a way to make a nice UX for it, all the others would follow. So in practice it seems perfectly reasonable to say "Matrix" when talking about the general UX found in apps implementing the Matrix protocol, doesn't it?
System level some use additional connections/recipients for spam/moderation and the moment you allow any invisible/visible group users in, there is a massive potential for an exploit.
Additionally you have the potential for forking off messaging to other users at the system level for either oversight or spam/moderation/other. Some of the compromised systems out there use this very well.
A sneaky way some of these "secure" messaging apps are also doing this is ghost participants in the chat that can essentially syphon off the messages even without a compromised client. The ghost participant is always under the guise of moderation or anti-spam or telemetry or some other proprietary shim.
> The code shows that the messages were secretly duplicated and sent to a “ghost” contact that was hidden from the users’ contact lists. [1]
Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats.
Other areas that "secure" messaging apps have holes in is the anti-spam/moderation systems that need to view messages and in the clients themselves who have access to the unencrypted content. This is also taking place in other client apps as well: VPN, password managers, extensions, wallets, even build systems and more. Many like VPNs have logs sent elsewhere but deleted locally -- access to entire machine and all network access. People are way too trusting of "secure" systems/apps that are very common today based on trust.
All of these apps/systems would pass code checks, reviews, security inspections and essentially be encrypted/"secure" though a copy is sent off to another area for review. At runtime the leak is in the direction of the data.
Then you also have governmental oversight that opens up holes that can be exploited.
On Ghost Users and Messaging Backdoors [2]
> to add a “ghost user” (or in some cases, a “ghost device”) to an existing group chat or calling session. In systems where group membership can be modified by the provider infrastructure, this could mostly be done via changes to the server-side components of the provider’s system.
> I say that it could mostly be done server-side, because there’s a wrinkle. Even if you modify the provider infrastructure to add unauthorized users to a conversation, most existing E2E systems do notify users when a new participant (or device) joins a conversation. Generally speaking, having a stranger wander into your conversation is a great way to notify criminals that the game’s afoot or what have you, so you’ll absolutely want to block this warning.
> While the GCHQ proposal doesn’t go into great detail, it seems to follow that any workable proposal will require providers to suppress those warning messages at the target’s device. This means the proposal will also require changes to the client application as well as the server-side infrastructure.
> (Certain apps like Signal are already somewhat hardened against these changes, because group chat setup is handled in an end-to-end encrypted/authenticated fashion by clients. This prevents the server from inserting new users without the collaboration of at least one group participant. At the moment, however, both WhatsApp and iMessage seem vulnerable to GCHQ’s proposed approach.)
[1] https://www.vice.com/en/article/v7veg8/anom-app-source-code-...
[2] https://blog.cryptographyengineering.com/2018/12/17/on-ghost...