Server and Development Stubs.
This commit is contained in:
parent
eeec0e4c40
commit
cb7c4c7dd7
|
@ -5,4 +5,9 @@
|
|||
- [Connectivity](./connectivity.md)
|
||||
- [Tapir](./tapir.md)
|
||||
- [Cwtch Library](./cwtch.md)
|
||||
- [Groups](./groups.md)
|
||||
- [Cwtch UI](./ui.md)
|
||||
- [Cwtch Server](./server.md)
|
||||
- [Development](./development.md)
|
||||
- [Deployment](./deployment.md)
|
||||
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
# Deployment
|
|
@ -0,0 +1,38 @@
|
|||
# Development
|
||||
|
||||
The main process to counter malicious actors in development of Cwtch is the
|
||||
openness of the process.
|
||||
|
||||
To enhance this openness, automated builds, testing and packaging are defined
|
||||
as part of the repositories - improving te robustness of the code base at every
|
||||
stage.
|
||||
|
||||
While individual tests aren't perfect, and all processes have gaps, we should be
|
||||
committed to make it as easy as possible to contribute to Cwtch while also
|
||||
building pipelines and processes that catch errors (unintential or malicious)
|
||||
as soon as possible.
|
||||
|
||||
### Risk: Developer Directly Pushes Malicious Code
|
||||
|
||||
**Status: Mitigated**
|
||||
|
||||
Master is currently locked and 3 Open Privacy staff members have permission
|
||||
to override it, and the responsibility of monitoring changes.
|
||||
|
||||
Further every new pull request and merge triggered automated builds & tests
|
||||
which trigger emails and audit logs.
|
||||
|
||||
The code is also open source and inspectable by anyone.
|
||||
|
||||
### Risk: Code Regressions
|
||||
|
||||
**Status: Partially Mitgated** (See individual project entries in this
|
||||
handbook for more information)
|
||||
|
||||
Our automated pipelines have the ability to catch regressions when that
|
||||
behaviour is detectable.
|
||||
|
||||
The greatest challenge is in defining how such regressions are detected for the
|
||||
[ui](./ui.md) - where behaviour isn't as strictly defined as it is for the
|
||||
individual libraries.
|
||||
|
|
@ -0,0 +1 @@
|
|||
# Groups
|
|
@ -0,0 +1,79 @@
|
|||
# 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 orignal Cwtch paper defined a set of properties that Cwtch Servers were
|
||||
expected to provide:
|
||||
|
||||
* Cwtch Server may be used by multiple groupsor 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 CwtchServer 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.
|
||||
|
||||
## Malcious 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 memebers 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.
|
||||
|
||||
The most developed idea is to bucket the messages on the server into discrete
|
||||
time windows and allow peers to fetch smaller batches, coupled with the
|
||||
underlying tor connection this technique should provide sufficient privacy
|
||||
- although the technique still needs formal verification.
|
||||
|
||||
# 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](https://openprivacy.ca/research/OPTR2019-01/) but note
|
||||
that this also requires further development.
|
Loading…
Reference in New Issue