Multi-Party Computation

A use case for multi-party computation could be voting with a small number of fixed participants. However, with large-scale voting, an unknown number of completed votes will be added to the tally. The challenge with multi-party computation protocols is adding dynamic behaviour, as the protocols are con- structed offline and agreed upon beforehand, where garbled circuits should not be reused. To compare multi-party computation, a simple tool was used to define a basic voting protocol.

TASTY is a Python tool developed for automating efficient secure two-party computation protocols using combinations of garbled circuits and homomor- phic encryption techniques [150][151]. Because both partially homomorphic encryption and fully homomorphic encryption are already being evaluated, we will just use the garbled circuit methods for two-party computation. TASTY can also perform analysis and benchmarking for protocol designs, which are used below. The configuration used for each protocol in TASTY had a long security level, which gives: symmetric/statistical as 128-bits, asymmetric as 3,248-bits, and curved as secp256r1. Both servers were on the localhost, with network traffic going through a pipe with a delay of 25ms in each direction.3

The first protocol design is given in Listing 3.5 where two servers (server and client in TASTY) add their values together. In terms of voting, the vote is split across the two servers such thatclientval+serverval =vwherev ∈ {0,1};

3_{This latency value was chosen by measuring the latency between nine AWS locations,}

where 22.5ms was the average latency to each locations nearest neighbour (rounded up

in this case 3 + (−2) = 1.

Listing 3.5:Simple TASTY voting design

def p r o t o c o l ( client , server , p a r a m s ) : LEN = 32

c l i e n t . val = S i g n e d ( b i t l e n = LEN , val =3) s e r v e r . val = S i g n e d ( b i t l e n = LEN , val = -2)

c l i e n t . g v a l = G a r b l e d ( b i t l e n = LEN , val = c l i e n t . val ) s e r v e r . g v a l = G a r b l e d ( b i t l e n = LEN , val = s e r v e r . val ) c l i e n t . o g v a l < <= s e r v e r . g v a l

c l i e n t . g r e s u l t = c l i e n t . o g v a l + c l i e n t . g v a l

c l i e n t . r e s u l t = S i g n e d ( b i t l e n = LEN +1 , val = c l i e n t . g r e s u l t ) c l i e n t . o u t p u t ( c l i e n t . r e s u l t )

The values are then garbled, and the server sends the garbled value to the client, which adds them and produces the result. To make this scheme compa- rable to the homomorphic encryption designs, there are a few elements missing. The first is that the result is not secured; to achieve this a random value r would need to be generated between the two servers wherer is not known to either. Each server could sum the votes then perform an addition between them, but this is not really comparable. Also, the key feature missing is that the vote is not verified to be yes or no, which would require more computa- tion than adding values. Listing 3.6 shows how multiple values were tallied together in this example protocol, where only two values are added together at one time.

Listing 3.6: Simple TASTY voting design for multiple votes

def p r o t o c o l ( client , server , p a r a m s ) : LEN = 32 c l i e n t . v a l 1 = S i g n e d ( b i t l e n = LEN , val =3) ... s e r v e r . g v a l 4 = G a r b l e d ( b i t l e n = LEN , val = s e r v e r . v a l 4 ) c l i e n t . o g v a l 1 < <= s e r v e r . g v a l 1 c l i e n t . o g v a l 2 < <= s e r v e r . g v a l 2 c l i e n t . o g v a l 3 < <= s e r v e r . g v a l 3 c l i e n t . o g v a l 4 < <= s e r v e r . g v a l 4 c l i e n t . g r e s u l t 1 = c l i e n t . o g v a l 1 + c l i e n t . g v a l 1 c l i e n t . g r e s u l t 2 = c l i e n t . o g v a l 2 + c l i e n t . g v a l 2 c l i e n t . g r e s u l t 3 = c l i e n t . o g v a l 3 + c l i e n t . g v a l 3 c l i e n t . g r e s u l t 4 = c l i e n t . o g v a l 4 + c l i e n t . g v a l 4 c l i e n t . g r e s u l t 1 2 = c l i e n t . g r e s u l t 1 + c l i e n t . g r e s u l t 2 c l i e n t . g r e s u l t 3 4 = c l i e n t . g r e s u l t 3 + c l i e n t . g r e s u l t 4 c l i e n t . g r e s u l t = c l i e n t . g r e s u l t 1 2 + c l i e n t . g r e s u l t 3 4 c l i e n t . r e s u l t = S i g n e d ( b i t l e n = LEN +6 , val = c l i e n t . g r e s u l t ) c l i e n t . o u t p u t ( c l i e n t . r e s u l t )

Protocols were generated for tallyingN votes, where each vote is split across the two servers. The metrics given in Table 3.3 are overall times for the setup

Table 3.3:Multi-party computation results for a simple voting protocol N Setup (ms) Online (ms) Setup C->S (KB) Setup S->C (KB) Online C->S (KB) Online S->C (KB) 1 457.09 55.08 3.38 4.89 0.12 1.56 2 856.34 157.78 6.67 10.93 0.24 3.11 3 1256.77 211.48 9.94 17.03 0.37 4.69 4 1374.16 318.10 8.06 27.56 0.49 6.25 5 1540.59 374.13 8.13 32.51 0.61 7.82 6 1798.90 484.97 8.22 37.29 0.73 9.39

and online phases, as well as the amount of data transferred during each phase. For some protocols, we could ignore the setup phase; however, if a verification protocol was designed to check that (clientval+serverval)∈ {0,1}, the setup phase would need to occur each time with this static protocol. The results show that not only is there a lot of data being transferred between the two servers but that the timing values are quite high to perform an addition operation, which is less complex than performing a verification.

3.2.5 Summary

For the voting use case, partially homomorphic encryption is the best option, because it gives the greatest overall performance, especially in the cloud. Even when compared to plain text processing, partially homomorphic encryption can tally votes faster than decrypting and encrypting values. The zero-knowledge proofs are the only limiting factor in terms of performance but are necessary for the verifiability required. However, performance in the cloud is not the only factor, as client-side performance can be important. Because the fully homomorphic encryption scheme only encrypts a single bit, it would have good client-side performance, but the cost of the cloud computation is currently too high. The use of multi-party computation protocols show promise for other applications; however, their lack of flexibility and reusability make the homomorphic encryption schemes better suited for this type of application.