Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party, and Metadata Resistant Applications

Warning: Cwtch is an experimental prototype. Please do not use it for anything where security, privacy, or anonymity is critical.

Communications metadata is known to be exploited by various adversaries to undermine the security of systems, to track victims and to conduct large scale social network analysis to feed mass surveillance. Metadata resistant tools are in their infancy and research into the construction and user experience of such tools is lacking.

Cwtch is an extension of the metadata resistant protocol Ricochet to support asynchronous, multi-peer group communications through the use of discardable, untrusted, anonymous infrastructure.

How Cwtch Works

Cwtch all starts with you, a peer:

Peers connect directly to each other via Ricochet. Through this connection they can verify each others identity and setup groups:

Group messaging is facilitated by Cwtch Servers, special long-lived trustless infrastructure that can be run by anyone - but that is trusted by no one.

Peers connect to the server and messages are relayed to all peers. However, only peers that possess the group secret are able to decrypt the messages and know who is speaking.

If a peer is offline, they are able to connect to the server later on and retrieve the messages:

Peers are free to listen to more than one server, and groups are able to change servers at any time, creating a dynamic, distributed and decentralized network:

Get Cwtch

Right now, Cwtch is only available via the source code which can be obtained via git or via go:

    go get cwtch.im/cwtch

To run a peer you can run our protoype cli application:

    go run app/cli/main.go

A Tor daemon running with the following configuration is currently also needed to run Cwtch:

    SOCKSPort 9050
    ControlPort 9051

Get Involved

• Email: team@cwtch.im
• Mailing List: cwtch-dev@openprivacy.ca

Open Research Questions

The only way to build secure software is to attack it from every angle. There are a number of limitations and problems with Cwtch, both as designed and as implemented in our prototype. We are working on many of these, but would like to invite researchers to work with us on new solutions, as well as find new problems.

Here are the problems we know about:

• The User Experience of Metadata Resistance Tools: Environments that offer metadata resistance are plagued with issues that impact usability, e.g. higher latencies than seen with centralized, metadata-driven systems, or dropped connections resulting from unstable anonymization networks. Additional research is needed to understand how users experience these kinds of failures, and how apps should handle and/or communicate them to users.
• Scalability: Heavily utilized Cwtch servers increase message latency and the resources a client requires to process messages. While Cwtch servers are designed to be cheap and easy to set up, and Cwtch peers are encouraged to move around, there is a clear balance to be found between increasing the anonymity set of a given Cwtch server (to prevent targeted disruptions) and the decentralization of Cwtch groups.
• The (Online) First Contact Problem: Cwtch requires that any two peers are online at the same time before a key exchange/group setup is possible. One potential way to overcome this is through encoding an additional public key and a Cwtch server address into a Cwtch peer identifier. This would allow peers to send encrypted messages to an offline Cwtch peer via a known server, with the same guarantees as a Cwtch group message. This approach is not without issues, as by encoding metadata into the Cwtch identifier we allow adversaries to mount partially targeted attacks (in particular denial-of-service attacks against the Cwtch server with the aim of disrupting new connections). However, the benefit of first contact without an online key exchange is likely worth the potential DoS risk in many threat models.
• Reliability: In Cwtch, servers have full control over the number of messages they store and for how long. This has an unfortunate impact on the reliability of group messages: if groups choose an unreliable server, they might find their messages have been dropped. While we provide a mechanism for detecting dropped/missing messages, we do not currently provide a way to recover from such failures. There are many possible strategies from asking peers to resend messages to moving to a different server, each one with benefits and drawbackss. A full evaluation of these approaches should be conducted to derive a practical solution
• Dicoverability of Servers: Much of the strength of Cwtch rests on the assumption that peers and groups can change groups at any time, and that servers are untrusted and discardable. However, in this paper we have not introduced any mechanism for finding new servers to use to host groups. We believe that such an advertising mechanism could be built over Cwtch itself.