-
Notifications
You must be signed in to change notification settings - Fork 0
Requirements
In this document, we look at the requirements of our Group Key Agreement protocol. Please note that some of the properties mentioned here require the support of our network.
The group initiator/creator should be able to start a group even when none of the other participants are online.
The complexity of the group set up should scale linearly with the number of participants. Key updates from members should scale sub-linearly.
The same group key agreement primitive should be usable for both group messaging and managing multiple devices owned by a single user.
Asynchronous group setup requires a network to store the setup information. When the participants come online they should be able to join the group solely based on the setup information previously published by the creator. In this sense, the network plays a very minimal role in the group setup.
Key agreement protocol should be based on well-known and time-tested cryptographic primitives.
This is related to the notion of asynchronous setup. The protocol shouldn't require roundtrip communication between the creator and participant before they participate in the group.
The computational burden should be the same for all the participants, except maybe for the group initiator/administrator.
There are two types of participants in a group: Administrators/managers and participants. Members of each type are trusted equally.
Participants can exit the group without restarting the protocol.
Participants can be added to the group without restarting the protocol.
Participants can update their keys without restarting the protocol.
Participants should have a consistent view of all participants and their roles in the group.
The following set of properties is common for most secure two-party messaging systems. Here we list the equivalent properties in a multi-party setting.
Messages are encrypted before they are stored on the network. Only group participants should be able to read the plaintext of encrypted messages.
Group participants agree on each other's identities (their long-term keys).
Group participants will reject messages that have been sent or tampered with by an outsider.
Forward secrecy is the property that an active network adversary who compromises some or all users should not be able to decrypt messages from before the compromise.
Post-compromise security is the property that an active network adversary who temporarily compromises some or all users should not be able to decrypt messages indefinitely after the compromise is healed.
All honest members of the group have a consistent linear/causal ordering of messages.
At any time after group creation, all active participants have the same view of the participant list.
All participants agree on the sequence of messages sent by each participant. This doesn't necessarily mean there is a global ordering of the messages in a group.
Group messages should have offline deniability. This means that a malicious group participant shouldn't be able to prove authorship to an external party long after the message is sent.
It should be possible for the participants of a group to communicate out of band or via pairwise secure channels while still preserving the conversation history in the group.