mulsigo

mulsigo

mulsigo is a tool enabling a group of person to sign a message without ever the private key being neither generated at one place nor stored at one place. The resulting public key is a valid EdDSA public key and the signatures are valid EdDSA signatures using Ed25519 (without any context,so the "old" draft RFC). One can import such a public key with a recent gpg version (> 2.1).

(UNDER DEVELOPMENT)

Disclaimer

WARNING: This software has not been peer reviewed at all, and is likely to be full of exploitable bugs. USE AT YOUR OWN RISK.

How does it work ?

Here's a draft-ish operational flow of the framework.

Group Creation

1. The server is launched with the user database.
2. Each participant connect to the server using their own user/pwd.
3. Each participant create its longterm self-signed public key (ed25519) and send it to everyone through the server.
4. Each participant collect the whole list of public keys and make an offline verification with other participants about the hash of the list.
5. If everything is correct, all participants store the group file for future use.

This whole step can also be done manually by copy/paste each individual public key into a single group file and distribute that file to each participant.

Distributed longterm key creation

1. The server is launched with srp, or tls or plain (not recommended).
2. Each user connect to the server
3. One user starts the distributed key generation protocol by sending the parameters t,n (threshold), and the gpg identifiers (name, email and comment) of the longterm distributed key to everyone through the server. The name is used to refer to this distributed longterm key so different keys can be generated by the same participant.
4. Each user sends their shares to everyone through the server. All shares created by each user is encrypted to the right recipient's public key so the server does not need to be trusted.
5. At the end of the protocol, each participant has a share of the longterm distributed key or an error occurred during the verification steps.
6. Each participant MUST verify offline that all participants have their share for the same distributed public key. If that is not the case, the protocol MUST abort.
7. To create a PGP valid signature, each participant runs the distributed signing protocol in order to self sign the longterm distributed pgp key. See next section.

Distributed Signing

1. The server is launched
2. Each user connects to the server
3. One user (the leader) starts the distributed signing protocol by sending to everyone the name of the distributed longterm key under which the signing must take place, and the message to sign.
4. Each user runs the distributed signing protocol by sending
   • their random shares to each other participants
   • their contribution to the signature to each other participants
5. The leader can issue a valid gpg signature under the distributed longterm public key !

Threat model

This software use a cryptographic threshold t-n signing scheme. In other words, it means that only t participants out of n are needed to sign. Any attacker willing to compromise the system and issue signatures on its own need to compromise at least t participants.

The server's role is only to be a proxy between users so there is no need to setup a server and open a port etc etc for each users. More importantly, the completely distributed protocol is much more complex under asynchronous network assumptions, and is still under active development at the DEDIS lab.

During the creation of group file, the server, if compromised, can modify the data but is likely to get caught because of the manual verification by each participant. In that case, the protocol MUST be aborted, and the server should most likely be formatted.

During the generation of the longterm distributed key and any subsequent signing protocol, the server can not tamper with any data because each packet is signed and most shares are encrypted. The server can however delay and drop messages. This behavior is likely to be detected during the longterm key generation, because of the manual verification of the signature (later, this could be changed to a BFT-CoSi signature to avoid an additional manual check). During the signing process, a compromised server is capable of DDoS-ing the protocol by refusing the proxy any messages, or less than t.

license

All code inside this repository is under the AGPL license. See LICENSE for more information.