~xaos/cnsprcy

[WIP] CNSPRCY connects your computers :^)
doc: start explaining configuration
doc: explain features
feat: implement Inline for key-value Pairs

refs

master
browse  log 
cnspr/v0.3.0
browse  .tar.gz 

clone

read-only
https://git.sr.ht/~xaos/cnsprcy
read/write
git@git.sr.ht:~xaos/cnsprcy

You can also use your local clone with git send-email.

#CNSPRCY (alpha)

CNSPRCY is a daemon process that connects your personal computing devices (i.e. desktop, laptop & phone but not wearables). By constantly attempting to establish and then maintain connections between the devices, it can act as a central source of information for applications and scripts that need to exchange data between your devices. Additionally, if a dedicated connection isn't required, messages can simply be sent in-protocol, invoking scripts (called "event handlers") on the receiving device.

The same daemon process runs on each device, operating a fully decentralized mesh network, using gossip-style event propagation to reduce and equally share the load across devices. It knows the status of all peers (i.e. whether they are reachable) at all times, and it exposes this information, including the IP addresses and latencies when available, over a UNIX socket. This socket can either be queried directly using JSON, or via the provided CLI application.

Because not all applications & scripts need to open a dedicated connection, CNSPRCY also makes it trivial to send messages between devices. Messages are part of the protocol and sent over the connections the daemon already maintains - as such they are also encrypted & authenticated using the ChaCha20-Poly1305 cipher suite. On the receiving device, a script is invoked with the message content and originator. To decide which script (obviously it may also be a binary) is invoked, each message contains a user-defined tag, which maps onto the directory structure and filenames in the handler directory. For more information, see event_handlers.md.

CNSPRCY only targets (recent) distributions of Linux. It is written entirely in (async) Rust, using the Tokio runtime. Its central inspiration is the serf "service orchestration and management tool", and it tries to bring it from its data-center / server context to that of personal computers.

#Current State

This Rust crate provides the cnsprcy library, which is used to implement the cnspr binary (also in this repository, under the cnspr branch). This binary resembles the serf binary, acting as both the daemon process (cnspr serve) and the client querying it (see cnspr help).

At this point, CNSPRCY is alpha-quality software and, while the underlying protocol and architecture of the daemon is reasonably well fleshed out, several important features are missing.

Among these is a mechanism for devices to discover each other in the same local network. This will be modeled (somewhat) after the way it is done in Syncthing, mainly using IP multicast (though likely mDNS Service Discovery) and perhaps eventually using a global "rendezvous" server.

More importantly, there are serious concerns about the security of the protocol as it stands (being based on on symmetric encryption with one key shared between all nodes).

Aside from that, see event_handlers.md and below for some of the features that are already implemented.

#Daemon Process

The daemon process listens for events from multiple sources:

  • network packets from other conspirators
  • changes to the network interfaces (using the rtnetlink interface to the kernel)
  • commands received on the IPC socket (i.e. the ones from cnspr).

It can be started using cnspr serve. To enable more verbose logging, set the RUST_LOG environment variable to trace, debug, info, or warn, e.g. by running RUST_LOG=debug cnspr serve.

#Key-Value Store

Access the distributed key-value store using the cnspr db sub-commands. Writes (using the set command) are broadcast to active peers immediately and will propagate to the rest eventually. Reads (using get or list) don't go through the CNSPRCY daemon but access the database directly instead.
Eventual consistency is achieved by using writer's unique identifiers as tiebreaks for concurrent writes to the same key.

#Inducting Conspirators

New devices can be added to the network interactively using the induct and join commands. They will attempt to discover each other using mDNS-SD and exchange the encryption key using public-key cryptography.

On the new device, start advertising with cnspr manage join and take note of its public key. On the device that's already part of the network, start looking for advertisements with cnspr manage induct. Once the inductee has been discovered, make sure that the public key matches what was shown on the new device. Then, send out the invitation and take note of this side's public key. Confirm that this public key also matches with the invitation received by the inductee and accept it.

#Removing Conspirators

Old devices can be removed from the network using cnspr manage disable, but only as long as they cooperate. If a device is compromised, the secret encryption key needs to be changed on all devices.

It may be interesting to note that because CNSPRCY is a fully decentralized protocol it is currently not possible for nodes to forget about the removed conspirator entirely.

#Funding

This project was awarded a grant through the NGI Assure Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 957073.