Tools and scripts for SRS generation via a Multi-Party Computation (MPC).
- Fetch the docker image:
$ docker pull clearmatics/zeth-mpc
- Start the container:
$ docker run -ti \
--env COORDINATOR_IP=<coordinator-ip> \
--net=host \
--name zeth-mpc-contributor clearmatics/zeth-mpc
- Once in the container, activate the virtual environment:
$ source env/bin/activate
- Zeth mpc executables (an optimized build from this repo, or from a binary distribution).
- python3 (>=3.7) and venv (
pip install venv
). - (Phase1 only) clone and build: https://github.com/clearmatics/powersoftau
- requires the rust build environment, including cargo
If necessary, follow instructions to build Zeth binary executables. Execute the following to install all further packages required for the MPC:
$ python -m venv env # create virtualenv
$ . env/bin/activate # activate virtualenv
(env) $ make setup # install
All commands given below assume that the above virtualenv is active. If the console has been closed between actions, reactivate the virtualenv as follows:
$ . env/bin/activate
(Adjust the path to run the command from a directory other than $ZETH/mpc
)
- Create a working directory for the contribution. (Note that when contributing multiple times to a single phase, or to multiple phases, it is recommended to create a directory for each contribution.)
(env) $ mkdir mpc_contrib
(env) $ cd mpc_contrib
All commands below are assumed to be executed in the working directory for the contribution.
- Generate a contributor keypair for authentication purposes throughout the MPC. In addition to generating a keypair, the command below will also generate a "key evidence" used to certify the public key shared with the coordinator. (This extra step is required to make sure that the contributor has knowledge of the secret key associated with the public key she registers to the coordinator)
(env) $ generate_key contributor.key
- Use the output (public key and key evidence) when registering as a participant
in the MPC. The file
contributor.key
is the contributor's secret key used to sign the contribution. Keep this protected - it could be used by an attacker to impersonate you and steal your place in the list of contributors, rendering your contribution invalid.
When requested, invoke the contribution computation (ensure the env is activated, and that commands are executed inside the working directory). Specify the URL (you should receive this from the coordinator, usually by email or during registration), and the contributor secret key.
For phase1:
(env) $ phase1_contribute https://<host>[:<port>] contributor.key
...
Digest of the contribution was:
00a769dc 5bce6cd6 8e679d5e b7f1f175
e410759e 33eb11b4 0fff9cb6 2d082165
8bfd09fe d8e10f51 3bd05cfa e7cb92cb
29ff0501 e51ff07e 3088a817 7a6ddb55
Digest written to: response.bin.digest
...
For phase2 (assuming mpc-client-phase2
is in the PATH
):
(env) $ phase2_contribute https://<host>[:<port>] contributor.key \
--mpc-tool $(which mpc-client-phase2)
...
Digest of the contribution was:
00a769dc 5bce6cd6 8e679d5e b7f1f175
e410759e 33eb11b4 0fff9cb6 2d082165
8bfd09fe d8e10f51 3bd05cfa e7cb92cb
29ff0501 e51ff07e 3088a817 7a6ddb55
Digest written to: response.bin.digest
...
Note: You may need to specify additional flags to these commands.
See phase1_contribute --help
and phase2_contribute --help
for all available
flags.
You will be asked to provide randomness by entering a random string and
pressing ENTER
. Once this is complete, the command will automatically perform
all necessary computation, write the results to a local file and upload to the
coordinator.
As part of the execution, the contribution digest is written to stdout, as
shown above. It is also written to response.bin.digest
in the working dir.
Keep this file (or make a note of the digest). It can be used at the end of
the process to verify that your contribution is correctly included in the final
MPC output.
(env) $ mkdir phase1_coordinator
(env) $ cd phase1_coordinator
or
(env) $ mkdir phase2_coordinator
(env) $ cd phase2_coordinator
Either self-signed or with a certificate chain from a trusted CA. (If using
self-signed certificates, the authority's certificate should be published and
clients instructed to download it and use the --server-certificate
flag when
contributing),
A self-signed certificate can be generated as below
(env) $ openssl req -x509 \
-nodes \
-newkey rsa:4096 \
-keyout key.pem \
-out cert.pem \
-days 365
Contributors should submit their email address and contribution verification keys before the MPC begins.
Create the file server_config.json
in the server working directory,
specifying properties of the MPC:
// server_config.json
{
"server": {
"contributors_file": "contributors.json",
"start_time_utc": "2019-10-02 17:00:00", # Time in UTC
"contribution_interval": "86400", # 24 hours (in seconds)
"tls_key": "key.pem",
"tls_certificate": "cert.pem",
"port": 8001
}
}
The servers for each phase (phase1 and phase2) also support options specific to that phase, which can be set in the config file. See the test configurations for phase1 and phase2 for full examples.
The contributors_file
field must point to a file specifying the ordered set
of contributors in the MPC. This file takes the form:
{
"contributors": [
{
"email": "[email protected]",
"verification_key": "308...eed4",
"key_evidence": "015b...71d8"
},
{
"email": "[email protected]",
"verification_key": "3081...0650",
"key_evidence": "0015...25d6"
},
...
]
}
See testdata/mpc_contributors.json for an example contributors file.
An easy way to allow contributors to register for the MPC is to publish a form online. Google Forms are widely used and provide a way to export the results of the form in csv format. The section below assumes that the registration process has been carried out using Google Forms.
The contributors_from_csv
command can be used to generate a
contributors.json
file from csv data output from Google Forms. Administrators
can thereby use Google Forms to allow participants to register and use this
command to automatically populate their contributors.json
file.
Ensure that email, public key, and evidence fields are present in the form, and
download the response data as a csv file. Flags to contributors_from_csv_
can
be used to specify the exact names of each field (see --help
for details).
The MPC coordinator server can notify participants by email when their
contribution time slot begins (when the previous contributor either finishes
his contribution, or his time slot expires). To enable email notifications, set
the email_server
, email_address
and email_password_file
fields to point to a
(tls enabled) mail server.
Phase2 requires the output from Phase1 to be processed before Phase2 can begin.
The following assumes that the Phase1 server directory is located in the
directory ../phase1_coordinator
:
(env) $ phase2_prepare ../phase1_coordinator
If the phase1_coordinator
directory is not available, a directory should be
created containing at least the final_output.bin
file, and a minimal
server_config.json
(which must specify the num_powers
property - the
maximum degree used in Phase1).
This process also relies on the pot-process
tool from the Zeth build. See
the output of phase2_prepare --help
for how to specify this.
Note that this process can take a significant amount of time.
Launch either phase1_server
or phase2_server
in the server working
directory.
(env) $ phase1_server
or
(env) $ phase2_server
In order for the results of Phase1 and Phase2 to be used, they must be combined
to produce a key-pair. This is performed by the create_keypair
command. It
should be run in the Phase2 directory, and similarly to phase2_prepare
,
requires a minimal Phase1 directory to be available (specified as an argument):
(env) $ create_keypair ../phase1_coordinator keypair.bin
The above assumes that the Phase1 server directory is located in
../phase1_coordinator
, relative to the (Phase2) working directory.
From the repository root, with the virtualenv activated:
(env) $ cd mpc
(env) $ make check