Scalable collective authority
Clone or download
Latest commit 77d2e0f Jan 16, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
authprox Fix integration tests Dec 13, 2018
bftcosi kyber.Point shouldn't be used as the key to a map Oct 9, 2018
blscosi BLS refusal uses nonce as challenge-response Dec 21, 2018
byzcoin Logging and error cleanup Jan 16, 2019
byzcoinx Rename blsftcosi package into blscosi Dec 19, 2018
calypso Add java test for calypso resharing Dec 12, 2018
cisc Fix cisc integration test Dec 18, 2018
conode Rename blsftcosi package into blscosi Dec 19, 2018
cosi Big Cleanup of Java Oct 5, 2018
darc Improve replay guard documentation Nov 7, 2018
dkg Fix dkg protocol tests. Dec 11, 2018
doc Changing default port to 7770 Nov 23, 2018
eventlog Address Jeff's comment Dec 21, 2018
evoting Changing default port to 7770 Nov 23, 2018
external Remind users that IV should not repeat Jan 16, 2019
ftcosi Rename blsftcosi package into blscosi Dec 19, 2018
helm-chart Changing default port to 7770 Nov 23, 2018
identity Rename blsftcosi package into blscosi Dec 19, 2018
messaging correctly shutting down propagation protocol Sep 7, 2018
personhood Implement signer counter to prevent replay attacks Nov 6, 2018
pop Rename blsftcosi package into blscosi Dec 19, 2018
scmgr Fix integration tests Dec 18, 2018
skipchain Logging and error cleanup Jan 16, 2019
stable Changing default port to 7770 Nov 23, 2018
status add a --host argument to status Nov 23, 2018
.gitattributes KyberJS: gitattributes to mark dist and doc as binary Jan 11, 2019
.gitignore Implement CALYPSO in Java Sep 7, 2018
.gitmodules Changing default port to 7770 Nov 23, 2018
.travis.yml Reenable kyber tests on Travis Dec 20, 2018
AUTHORS AGPL-license (#628) Nov 21, 2016
CHANGELOG Cothority import changed to onet (#736) Dec 15, 2016
CLAC AGPL-license (#628) Nov 21, 2016
CLAI AGPL-license (#628) Nov 21, 2016 Adding more documentation Mar 13, 2018 Adding more documentation Mar 13, 2018
CONTRIBUTION AGPL-license (#628) Nov 21, 2016
LICENSE AGPL-license (#628) Nov 21, 2016
LICENSE.AGPL AGPL-license (#628) Nov 21, 2016
Makefile Disable stable build Dec 18, 2018 Changing default port to 7770 Nov 23, 2018
dedis-cothority.toml Fix to identity service to work with TLS Feb 19, 2018
doc.go Improve .md files Mar 19, 2018 Fix integration tests Dec 13, 2018 removing unused pop-test and prepare for stderr output in onet Nov 26, 2018
proto.awk Added packed=true feature to proto.awk Nov 6, 2018 Protobuf fixes: skipchain zigzag encoding and protoc version Nov 5, 2018
suite.go Fixes so that suite can be changed at runtime Jan 25, 2018
suite_vartime.go Fixes so that suite can be changed at runtime Jan 25, 2018 Address Jeff's comment Dec 21, 2018

Build Status Coverage Status

Navigation: DEDIS :: Cothority


The collective authority (cothority) project provides a framework for development, analysis, and deployment of decentralized, distributed (cryptographic) protocols. A given set of servers running these protocols is referred to as a collective authority or cothority. Individual servers are called cothority servers or conodes. The code in this repository allows you to access the services of a cothority and/or run your own conode. The cothority project is developed and maintained by the DEDIS lab at EPFL.

This is an overview of this README:

  • Documentation with links to different parts of the cothority
    • Topically ordered explains the different functional pieces from the cothority from a research point of view
    • Network ordered gives an overview from a networking point of view
    • Links collects links to other repositories, papers and webpages that are important to the cothority.
  • 1st steps giving two example apps ready to use
  • Participating on how to help us getting cothority even better

Don't forget that the cothority is part of a bigger environment.


The software in this repository is highly experimental and under heavy development. Do not use it for anything security-critical yet.

All usage is at your own risk!

Versioning and Roadmap

We started to work on a 6-monthly cycle, synched up with the semesters at EPFL. From March to August we keep changes on the master-branch non-API breaking. Master and the current version are kept in sync. In September, we allow API-breaking changes in master and only selectively update the stable branch. End of February we freeze the current development in a stable branch and start again a non-breaking period of 6 months.

The current master branch is stable till the end of August 2018. If you are starting new work with this repository, use instead. The source code for this stable branch is here.

During 2018, we hope to bring you the following new pieces:

  • Cross platform mobile application to interact with the pop service
  • ByzCoin implementation using key/value pair storage and protected by darcs

Other pieces we hope to achieve in 2018:

  • Distributed internet archival functionality
  • New status-website of the cothority
  • Catena integration for skipchains

And some projects are private for the moment, but we hope to make them public as soon as possible.


The goal of the cothority is to collect projects that handle aspects of collective authorities to support scalable, self-organizing communities. In this document we present the apps that are directly runnable from the cothority, as well as links to the services and protocols used in the cothority.

A cothority is a set of conodes that work together to offer collective authority services. This is used to create distributed and decentralized services where no single point of failure can put the whole system in jeopardy. Conodes communicate with each other using protocols that are short-lived, specific tasks with an outcome that can be read by services. Each conode has a set of services that can be contacted through a well-defined API from the outside. The communication through the API is done with a homebrewn protobuf over websockets implementation.

Topically ordered

When looking at the cothority modules from a topical point of view, we can break it up as follows:

|                          |APPLICATIONS|                          |
|     Onchain-Secrets      +------------+     Proof of Personhood  |
|                                                                  |
|       ByzCoin                 Status            E-voting         |
|                        |BUILDING BLOCKS|                         |
| Consensus              +---------------+       Key Sharding      |
|  - Skipchain                                    - Re-encryption  |
|  - BFT         General Crypto    Messaging      - Decryption     |
|  - Collective   - Neff Shuffle    - Broadcast   - Distributed    |
|    Signing      - RandHerd        - Propagate     Key Generation |
|                 - RandHound                                      |
|                                                                  |


Applications in cothority use different libraries and are the highest level of abstraction in our framework.

Here you get a list of all applications in the cothority.

There is one very special application that is considered apart - it's the conode itself, which holds all protocols and services and can be run as a service on a server.

What a Conode can do for you

Building Blocks

Building blocks are grouped in terms of research units and don't have a special representation in code. Also, the General Crypto library is more of a collection of different protocols.

Here you get a list of all building blocks in the cothority.

Network Ordered

If we look at the cothority from a purely networking point of view, we can describe it as follows:

              |CLI, JavaScript, | Frontend        
              |Java             |                 
| Conode,     | Services        | Client to Conode
| Simulations |-----------------+                 
|             | Protocols       | Conode to Conode


  • Pulsar - publicly verifiable randomness
  • Status - status of our test-network
  • PoP - 2nd pop-party ever held

Command Line Interfaces

Command line interfaces (CLI) are used to communicate with one or more conodes. All CLIs need to have one or more conodes installed. For the two CLIs in first steps, you can use the running conodes at EPFL/DEDIS. If you want to test the other CLIs, you might need to set up a small network (often 3 nodes is enough) of conodes on your local computer to test it.

Here you get a list of all available CLIs in the cothority.


Every app communicates with one or more services to interact with one or more conodes. This is a list of available services that can be contacted on a running conode. Some of the services are open to all, while others might require authentication through a PIN or a public key. Most of the apps and services have the same name, but some are not available as an app or have more than one app using it.

Here you get a list of all available services in the cothority.


Protocols are used to communicate between conodes and execute cryptographic exchanges. This can be to form a collective signature, create a consensus on a new state, or simply to propagate a new block from a skipchain. Some protocols are useful for different services, while others are very service-specific. Most of the protocols have a paper that is describing how the protocol should perform and that compares it to other protocols.

Here you get a list of all available protocols in the cothority.


Cothority grew up as a research instrument, so one of its advantages is to have a framework to create simulations and running them locally or on remote servers. Some of the protocols presented here do have the simulation code. Check it out here: Cothority Simulations.

First steps

If you're just curious how things work, you can check the status of our test network or create a collective signature using our running nodes:


To get the status of the conodes in the cothority, first install the status binary:

go get
export DEDIS_GROUP=$(go env GOPATH)/src/

Now you can run it by giving the definition of the dedis-cothority on the command line:

status --group $DEDIS_GROUP

Collective Signing

Another service available is fault-tolerant collective signing, or ftCoSi. It requests a collective signature from a set of conodes. The signature is created on a given input data. For installation, type:

go get
export DEDIS_GROUP=$(go env GOPATH)/src/

Now you can create a file and have it signed by the cothority:

date > /tmp/my_file
ftcosi sign --group $DEDIS_GROUP /tmp/my_file | tee sig.json

And later somebody can verify the signature is correct by running the following command:

ftcosi verify --group $DEDIS_GROUP --signature sig.json /tmp/my_file

If everything is correct, it should print

[+] OK: Signature is valid.

Participating in the cothority

There are different ways to participate in the cothority project. A first step is to simply test the different CLI applications in this repository and tell us what were your difficulties or what you would like to use them for.

A next step is to set up your own conode and participate in the

Setting up your own conode

A conode is a server program that includes all protocols and services. It can be run on a public facing server, but for testing purposes it's also possible to set up a network on a machine and only let it be accessed locally.

  • conode is the cothority server, a special app that includes all services and protocols.
  • How to run a conode gives an overview of the environment where a conode can be run
  • DEDIS-cothority explains how to join the DEDIS-cothority


If you want to contribute to Cothority-ONet, please have a look at CONTRIBUTION for licensing details. Once you are OK with those, you can have a look at our coding-guidelines in Coding. In short, we use the github-issues to communicate and pull-requests to do code-review. Travis makes sure that everything goes smoothly. And we'd like to have good code-coverage.


The software in this repository is put under a dual-licensing scheme: In general all of the provided code is open source via GNU/AGPL 3.0, please see the LICENSE file for more details. If you intend to use the cothority code for commercial purposes, please contact us to get a commercial license.


We are always happy to hear about your experiences with the cothority project. Feel free to contact us on our mailing list or by email.

Who is using our code?

This is a list of people outside of DEDIS who is using our codebase for research or applied projects. If you have an interesting project that you would like to have listed here, please contact us at

  • Unlynx - A decentralized privacy-preserving data sharing tool
  • Medco - Privacy preserving medical data sharing
  • ByzGen - Tracking and secure storage of digital and hard assets
  • PDCi2b2 - Private Data Characterization for
  • i2b2