3 ms·

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

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.

snarf21 4y ago
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.
- iforgotpassword 4y ago
  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.
- motohagiography 4y ago
  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.

snarf21 4y ago

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.

iforgotpassword 4y ago
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.
motohagiography 4y ago
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.