Cwtch Server
The goal of the Cwtch protocol is to enable group communication through Untrusted Infrastructure.
Unlike in relay-based schemes where the groups assign a leader, set of leaders, or a trusted third party server to ensure that every member of the group can send and receive messages in a timely manner (even if members are offline) - untrusted infrastructure has a goal of realizing those properties without the assumption of trust.
The original Cwtch paper defined a set of properties that Cwtch Servers were expected to provide:
- Cwtch Server may be used by multiple groups or just one.
- A Cwtch Server, without collaboration of a group member, should never learn the identity of participants within a group.
- A Cwtch Server should never learn the content of any communication.
- A Cwtch Server should never be able to distinguish messages as belonging to a particular group.
We note here that these properties are a superset of the design aims of Private Information Retrieval structures.
Malicious Servers
We expect the presence of malicious entities within the Cwtch ecosystem.
We also prioritize decentralization and permissionless entry into the ecosystem and as such we do not base any security claims on the following:
- Any non-collusion assumptions between a set of Cwtch servers
- Any third-party defined verification process
Peers themselves are encouraged to set up and run Cwtch servers where they can guarantee more efficient properties by relaxing trust and security assumptions - however, by default, we design the protocol to be secure without these assumptions - sacrificing efficiency where necessary.
Detectable Faults
- If a Cwtch server fails to relay a specific message to a subset of group members then there will be a detectable gap in the message tree of certain peers that can be discovered through peer-to-peer gossip.
- A Cwtch server cannot modify any message without the key material known to the group (any attempt to do so for a subset of group members will result in identical behavior to failing to relay a message).
- While a server can duplicate messages, these will have no impact on the group message tree (because of encryption, nonces and message identities) - the source of the duplication is not knowable to a peer.
Efficiency
As of writing, only 1 protocol is known for achieving the desired properties, naive PIR or "the server sends everything, and the peers sift through it".
This has an obvious impact on bandwidth efficiency, especially for peers using mobile devices, as such we are actively developing new protocols in which the privacy and efficiency guarantees can be traded-off in different ways.
As of writing, the servers allow both a complete download of all stored messages, and a request to download messages from a certain specified message.
All peers when they first join a group on a new server download all messages from the server, and from then on download only new messages.
Note: This behaviour does permit a mild form of metadata analysis. The server can new messages for each suspected unique profile, and then use these unique message signatures to track unique sessions over time ( via requests for new messages).
This is mitigated by 2 confounding factors:
- Profiles can refresh their connections at any time - resulting in fresh server session.
- Profiles can "resync" from a server at any time - resulting in a new call to download all messages. The most common usecase for this behaviour is to fetch older messages from a group.
In combination, these 2 mitigations place bounds on what the server is able to infer however we still cannot provide full metadata-resistance.
For potential future solutions to this problem see Niwl
Protecting the Server from Malicious Peers
The main risk to servers come in the form of spam generated by peers. In the prototype of Cwtch a spamguard mechanism was put in place that required peers to conduct some arbitrary proof of work given a server-specified parameter.
This is not a robust solution in the presence of a determined adversary with a significant amount of resources, and thus one of the main external risks to the Cwtch system becomes censorship-via-resource exhaustion.
We have outlined a potential solution to this in token based services but note that this also requires further development.