So useful to talk about protocols like this and a pleasure to read. I look forward to going through these protocols later today.
However, to take it there, I'd conjecture that the limit on the best possible group security is being able to verify the integrity of group membership on a per-message basis, and use some kind of forward secrecy / ratchet whereby the given message key can only be derived from being a verified member of the group of the time of the message.
The only way I think we know how to do that is with consensus proofs about the composition of the group membership. For each message, you would need to encrypt it with a group message key that is derived with an authenticated proof of group membership that includes only all authorized members. It's like there is a direct trade off between the complexity class of the protocol/algorithm, and the security guarantees of the protocol.
The best secuirty outcome is that only a member during the period of that message can recieve and disclose the plaintext, and without some way of diverisfying the plaintext per user, you don't know which user leaked it. The other limit appears to be that if you get a message from the group, you can't know who else is in the reciever group - only that the complete group may have r ecieved it.
Just for discussion sake, I think there may be some high level lemmas about the necessary trade offs in these protocols.
Yeah, it seems like we'd be safer with groups just being a convenience layer on top of peer-to-peer messaging and when you send to the group you are always just sending N messages to the group as you know it at that moment.
It seems like a totally different use case than p2p, not a matter of scaling a bidirectoinal one, but designing a multiparty one from scratch. The key management for push, poll, or pubsub are each totally different as well.
Imo, the threat models for most protocols aren't well defined, so we get this collection of techniques and features without a specific set of guarantees and caveats or limitations (even though that's what a formal protocol spec is supposed to be, afaik).
The group protocol threat model can be really diverse, with radically different solutions to it. Features like deniable participation, forward secrecy, persistant identity, anonymity, dynamic group size, sender authentication, recipient authentication, proof of delivery, proof of receipt, steganographic capabilities, key rotation, single vs. limited use keys, message key persistance, and then combining that into key derivation with sufficient entropy to provide assurances - are almost unique to each threat actor.
The attack mitigations are also a function of the threat model, and even talking about threat models without actively acknowledging them and conspiring against their actors can be a very nuanced and oblique discussion.
A few messengers like threema do that already. It's simple and boring, but so much easier to get right. If you don't have crazy large groups, this is fine.
If you can get code to run on a server which can trigger Hertzbleed, beit a virtual server where you have no control over what other people run on their virtual server instance, or you can employ a virtual cpu like the NSO iMessage gif exploit but program virtual gif cpu to do more than whats detailed in the NSO iMessage gif exploit, do private messaging platforms like WhatsApp have much privacy? I know people like evidence including the legal system, most of the time, but stealth weapons have to be captured in order to obtain the evidence.
Yes. Being able to target specific systems with specific exploits that are worth hundreds of thousands of euros, and using it risks the vulnerability being fixed, is very very different from people on encrypted messengers having no privacy at all (compare it to slack or IRC). Encryption still serves a propose here. The /NS[OA]/ is not the only attacker we're defending from and they, too, have the aforementioned restrictions.
However, to take it there, I'd conjecture that the limit on the best possible group security is being able to verify the integrity of group membership on a per-message basis, and use some kind of forward secrecy / ratchet whereby the given message key can only be derived from being a verified member of the group of the time of the message.
The only way I think we know how to do that is with consensus proofs about the composition of the group membership. For each message, you would need to encrypt it with a group message key that is derived with an authenticated proof of group membership that includes only all authorized members. It's like there is a direct trade off between the complexity class of the protocol/algorithm, and the security guarantees of the protocol.
The best secuirty outcome is that only a member during the period of that message can recieve and disclose the plaintext, and without some way of diverisfying the plaintext per user, you don't know which user leaked it. The other limit appears to be that if you get a message from the group, you can't know who else is in the reciever group - only that the complete group may have r ecieved it.
Just for discussion sake, I think there may be some high level lemmas about the necessary trade offs in these protocols.