Secure Multiparty Computation (MPC)
Currently, proof generation is supported with two different MPC protocols:
- 3-party replicated secret sharing (based on ABY31) with semi-honest security
- N-party Shamir secret sharing2 (based on DN073) with semi-honest security
Notation
With we denote that is additively secret shared amongst parties, such that and . With we denote that is binary secret shared amongst parties, such that and . With we denote that is Shamir secret shared amongst parties, such that and such that is a polynomial of degree with . Similar, for a group element in an additive Group (e.g., elliptic curve groups) we denote by its additive secret sharing amongst parties, and by its Shamir sharing, such that . Furthermore, indices of shares are taken modulo the number of parties.
3-Party Replicated Sharing
Replicated secret sharing is based on additive secret sharing, with the twist that each party has multiple additive shares. Thus, in the 3-party case a secret is shared the following way. First, the is split into three random shares such that and each party gets two shares:
Rng Setup
Random values are required during many parts of MPC executions. For cheaper randomness generation, correlated random number generators are set up before protocol execution.
Random Values
In order to create random shares , random additive shares of (i.e., ), or random binary shares of (i.e., ) without interaction, Rep3 sets up a correlated random number generator during the setup phase. Each party chooses a seed and sends it to the next party . Thus, each party has two seeds and can set up an RNG's, where two party are able to create the same random numbers:
Binary To Arithmetic Conversion
For the binary to arithmetic conversion, we need correlated randomness as well. The goal is to setup RNG's, such that:
In other words, and can use RNG1 create the same field element, while all parties can sample valid shares for it. Similar, and can use RNG2 to create the same field element, while all parties can sample valid shares for it. This setup can be achieved by sampling seeds from the already set up RNG for shared random values and resharing the seeds correctly.
Supported operations
Linear Operations
Due to being based on additive secret sharing, linear operations can be performed on shares without party interaction.
- Constant addition:
- Share addition:
- Constant Multiplication:
Similar, linear operations can be computed locally in the binary domain as well.
- Constant addition:
- Share addition:
- Constant Multiplication:
Multiplications
One main advantage of replicated secret sharing is the presence of a simple multiplication protocol. First, due to having two additive shares, each party can calculate an additive share of the result without interaction. For , is a valid additive share of .
Thus, multiplications involve a local operation followed by a resharing of the result to translate the additive share to a replicated share. Resharing requires to randomize the share to not leak any information to the other party. For that reason, a fresh random share of zero is added, which can be sampled locally without party interaction (see RNG setup).
Thus, party calculates:
The resharing, thereby, is simply implemented as sending to .
AND
AND gates follow directly from multiplications:
Arithmetic to Binary Conversion
In replicated sharing over rings (e.g., ABY3), arithmetic to binary conversion of a share is implemented by first locally splitting the shares to valid binary sharings, i.e., , , and and combining them in MPC using binary addition circuits. Then is a valid binary sharing of . This approach works because binary addition circuits implicitly perform modular reductions mod .
Thus, in we have to include the mod reductions manually in the circuit. For improved performance, we use the following protocol to translate :
- samples to be a new random binary share of
- Set
- calculates
- It follows that is a valid binary sharing of
- sends its share of to
- Each party now has a valid binary replicated sharing of
- The parties compute a binary adder circuit of bits to sum up and to get with bits (including overflow bit).
- The parties compute the subtraction of inside a binary circuit to get .
- The -th bit of indicates an overflow of the subtraction. If an overflow occurs, the result should be the first bits of , otherwise the first bits of . This if statement can be computed with a CMUX gate.
Binary to Arithmetic Conversion
For the binary to arithmetic conversion, the general strategy for replicated sharing is the following. We sample random binary shares and using the special correlated randomness, such that gets both values in addition to it's shares, while and get and in clear respectively. Then we compute a binary circuit to add . Finally, we open to and . The arithmetic shares then are .
To account for modular reductions in finite fields, we follow a similar strategy as for the arithmetic to binary conversion to translate :
- samples to be a new random binary share of
- samples using RNG2 and sets ;
- samples using RNG1 and sets ;
- samples using RNG1 and using RNG2, sets , , and ;
- It follows that is a valid binary sharing of
- sends its share of to
- Each party now has a valid binary replicated sharing of
- The parties compute a binary adder circuit of bits to sum up and to get with bits (including overflow bit).
- The parties compute the subtraction of inside a binary circuit to get .
- The -th bit of indicates an overflow of the subtraction. If an overflow occurs, should be the first bits of , otherwise the first bits of . This if statement can be computed with a CMUX gate.
- We open to and
- The final sharing is and each party has (only) access to the shares it requires for the replication.
Bit Injection
To translate a single shared bit to a arithmetic sharing, we perform share splitting and create valid arithmetic shares of the shares: , , and . Then, we combine the shares by calculating arithmetic XORs: , where .
Binary Addition Circuits
As mentioned in the arithmetic to binary conversions, we need binary addition circuits. Since the bitlength of the used prime fields is large, we use depth-optimized carry-lookahead adders for the conversions. Currently, we implement Kogge-Stone adders, since these can be computed efficiently using shifts and AND/XOR gates without extracting specific bits.
The general structure of a Kogge-Stone adder to add two binary values is to first compute and , where is the -th bit of . Then, and are combined using a circuit with logarithmic depth (in the bitsize). This circuit is implemented in the kogge_stone_inner
function.
For binary subtraction circuits, we basically compute an addition circuit with the two's complement of . Thus, we essentially compute . If is public, the can directly be computed and the result is just fed into the Kogge-Stone adder. If is shared, we invert all bits and set the carry-in flag for the Kogge-Stone adder. This simulates two's complement calculation. The set carry-in flag has the following effects: First, must additionally be XORed by . Finally, the LSB of the result of the Kogge-Stone circuit needs to be flipped.
Reconstruction
Reconstruction of a value is implemented as sending to . Then each party has all shares.
Security
Our implementation provides semi-honest security with honest majority, i.e., the scheme is secure if all parties follow the protocol honestly and no servers collude.
Shamir Secret Sharing
Shamir secret sharing is a different way of instantiating a linear secret sharing scheme which is based on polynomials. To share a value , one first has to sample a random polynomial of degree , where is in the constant term. I.e., one samples randomly from and sets: . The share of party then is . In other words, , where .
Reconstruction then works via lagrange interpolation of any shares: , where is the corresponding lagrange coefficient.
Supported operations
Linear Operations
Shamir's secret sharing allows, similar to additive sharing, to compute linear functions locally without party interaction:
- Constant addition:
- Share addition:
- Constant Multiplication:
Multiplications
RNG Setup
For the degree reduction step after a multiplication we require degree- and degree- sharings of the same random value . We generate these values following the techniques proposed in DN07, to generate random pairs at once:
- Each party generates a random value and shares it as degree- share and degree- share to the other parties.
- After receiving the all shares, one sets and .
- Calculate and , where is a Vandermonde matrix.
- The pairs for are then valid random shares which can be used for resharing.
For simplicity we use the following Vandermonde matrix:
Reconstruction
Reconstruction is currently implemented as sending its share to the next parties. Then, each party has shares to reconstruct the secret.
Security
Our implementation provides semi-honest security with honest majority, i.e., the scheme is secure if all parties follow the protocol honestly and at most servers collude. can, thereby, be chosen to be .
MPC for group operations
So far, we only discussed MPC for field elements . However, one can easily extend it to MPC over Group elements . W.l.o.g. we will use the notation for additive groups (e.g., elliptic curve groups). A secret share can be translated to a shared group element by , where is a generator of . Then, is a valid share of . Linear operations directly follow from the used linear secret sharing scheme: . Shared scalar multiplications also follow from the secret sharing scheme: .
Shamir vs Rep3
Shamir and Rep3 are both linear secret sharing schemes which provide semi-honest security with honest-majority. However, they have some important differences.
- Shamir can be instantiated with parties, while Rep3 is limited to parties.
- In Shamir, each share is just one field element , while in Rep3 each share is composed of two field elements.
- In Shamir, the overhead on the CPU is significantly smaller compared to Rep3, where each operation is applied to two shares.
- Rep3 allows efficient arithmetic-to-binary conversions.
Witness Extension
Due to not having an efficient arithmetic to binary conversion, we do not have a witness extension implementation for Shamir sharing at the moment. However, we provide a bridge implementation, which can translate Rep3 shares to 3-party Shamir shares (with threshold/poly-degree ).
This bridge works by first letting translate its first additive share to a Shamir share by dividing by the corresponding lagrange coefficient. This, however, creates a 3-party Shamir sharing with threshold/poly-degree . Thus, we perform the same degree-reduction step, which is also required after a Shamir multiplication.