The purpose of this document is to document approaches to multi-peer communication within Cwtch. It is clear that traditional conceptualizations & metaphors around secure group chat don't translate well within a metadata resistant environment, and as such it is important that we develop strong metaphors and intuitive expectations around multi-peer communication.
Metaphors
-
A conversation - the traditional conceptualization of group messaging as being an ongoing conversation between the participants. Unfortunately this metaphor has many drawbacks within a metadata resistant environment, the main one being that a conversation presupposes a set number of knowable participants and group management is elevated to a first-class function within the model. Group management within an environment like Cwtch actively goes against the grain of the design, increasing inefficiencies. Safe cryptographic gorup management is an active area of academic study and the best current solutions rely on reliable transport between peers.
-
A community noticeboard - within this model we imagine that peers post to the noticeboard and that others later download the contents of the noticeboard, additionly they can also post their own content to the noticeboard. This metaphor provides some advantages: it more directly abstracts the role of the cwtch server, concepts such as messages timing out of the servers buffer are easy to model as "newer posts being pinned over older posts" etc.
-
A gathering place - an alternative model to the noticeboard is the "gathering place", by conceptualizing a keyspace as a place we better represent the consequences of key loss/discovery (e.g. if you always hold your secret meetings at a particular coffee shop and then the location gets leaked your only alternative is to move to a different place). By allowing people to easily fork groups and move to somewhere else, we can build an intuitive interface for understanding group privacy without reaching for heavier primitives that potentially place a burden on the infrastructure.
Throughout the rest of this document we will refer to a collection of cwtch peers interacting with eachother over a common (set of) key(s) as a Place. Peers will be Invited to Join Places, Post messages to Places, they can also Leave a Place and Fork an existing Place.
The actions are summarized below:
- CREATE - a peer initializes a new encryption key and selects a server (or set of servers) to associated with their place. They distirbute this key to other peers via an invitation.
- INVITE - a peer gives an existing peer the key under which messages associated with a Place are encrypted.
- JOIN - a peer connects to the Cwtch server (or set of servers) hosting the messages from a particular Place
- FORK - a peer creates a new encryption key and selects a server (or set of servers) to associated with a derivative of an existing place. They distribute this key to other peers via an invitation.
- LEAVE - a peer destroys the key material for decrypting messages associated with a given Place.
- POST - a peer encrypts a message undern the key associated with a given Place and sends it to the associated cwtch server.
Additional Requirements for Places
Following on from the above sketch of properies, we would also like to consider a few more complex structures:
Asymmetric Privileges
A small set of people who can post messages to a Place vs. a large number of people that can read it. Such a structure intuitively fits well within a Cwtch type system where broadcast is a fundemental property.
Achieving such privileges can be done naively through a client side check, but this feels "hacky". Other potential approaches include:
- Broadcast Encryption - the best methods involve encrypted the same message with multiple different keys (having distributed these keys to peers). This would overwhelm cwtch servers and is not a good approach.
- Blinded Signatures Verified During Posting - another option would be to lock down the act of posting a message to a server, only allowing those with a (blinded) signature to post. Such an approach naturally leaks information to the server about the set of people publishing through the server (but not readers) and may be a viable approach for community run infrastructure. However the risks of such an approach are unquantified and as such this document proposes we leave this as a future research question.
- PIR - We have also looked at PIR based designs to achieve asymmetic privileges, through experiments we have determined that while PIR on Cwtch data is feasible, it would put tremendous computational burden on the Servers as well as drastically increase latency. As such, until more performant primitives are implemented PIR is likely to remain an unsuitable approach.
Limited Bandwidth
Cwtch servers are expected to be range in capabilities but on the peer side we expect many Peers to be operating on devices with minimal bandwidth / computational requirements. As such our current design of only allowing peers to Fetch everything or nothing is less than ideal.
This document proposes 2 changes in lib-cwtch to lessen this burden without impacting metadata resistance:
- Switch the server from storing messages oldest->newset to newset->oldest AND allow peers to download either everything or the last X messages (where for the sake of argument we will fix X to some small number). * This allows the server to distinguish between new peers and returning peers, and potentially in some scenarios allows peers to correlate access across sessions (but not Places or Message posting) * Even given the above the potential savings on mobile peers constantly disconnecting and reconnecting would be substantial. Risk can further be mitigated by allowing peers the option of always downloading everything, at the cost of peer bandwidth.
- In addition to the above, we also propose removing the 65k cap from ricochet messages AND/OR allow treating server download as a single file tranfer. This will greatly improve download time (with an additional small saving on overhead and peer computational power use)
Forward Secrecy & Place Membership
Two non-intuitive and potentially controversial properties of Cwtch Places are the lack of forward secrecy (everyone uses the same static key, forever) and the lack of an ability to enforce membership on a place (if a key is leaked then anyone can listen in without being known).
Such properties arise as a result of the metadata resistant environment Cwtch is designed to operate in. We cannot assume that every message will be seen by every member of a given collective of peers. As such groups lack properties of best in class group messaging systems.
The most dangerous risk is a party intercepting all communication from know Cwtch servers in the hopes that they can one day decrypt this traffic (through a compromised key etc. etc.).
We introuce the concept of Forking in part to mitigate this. We intend to design the UX to make it easy to initiate and manage a fork. For smaller groups, we might want to explore the idea of making groups ephemeral i.e not suitable for long term storage, but for short 1-off tasks that eventually get phased out and replaced by other groups.
When it comes to managing memeberships, no solution is perfect, a hacked or compromised peer can result in surveillance (we note that this risk is the same regardless of the underlying cryptography). We can ensure that honest parties are honest, but not that compromised parties are not-compromised.
As such it is essential that the UX design emphasis the differences of p2p and group message flows and directs communication towards ephemeral p2p sessions and 1-off groups. This not only mitigates the above risks, but also potentially minimizes the bandwidth costs by spreading them across servers.
Proposed Actions
The following table summarizes the proposed actions from this document:
| Project | Action | Link (if accepted) |
|---|---|---|
| Cwtch | Updates Server Storage to be Newest->Oldest | |
| Cwtch | Updates Server Fetch to accept a (latest or everything) parameter | |
| Ricochet | Design & Implement file transfer channel | |
| Cwtch | Update Server Fetch to use File Transfer Channel | |
| Cwtch | Change 'Group' API to the Places API | |
| Cwtch UI | STORY: Design & Places as a UX |
Potential Future Stories
- Membership-only Publishing Support for Servers (PIR or Blinded Signature Based)