3 crypto schemes for liquid democracy (II)

Jul 19, 2016

In part 1 we showed the first of three schemes supporting liquid democracy. Scheme Mixnet/Mixnet combined results from two tallies to obtain each election result. All three schemes follow the two tally pattern, and differ in how the combination is made, resulting in slightly different privacy properties. Following is scheme Homomorphic/Mixnet

Above, boxes with double borders represent encrypted votes. As with the Mixnet/Mixnet scheme, we see two separate vote casting components, the cross-election vote for delegates and the per-election overriding direct votes. In this scheme, however, delegate votes are processed differently. The first arrow marked with a ‘+’ represents a homomorphic tally, which as we discussed in a previous post can be implemented via the additively homomorphic property of exponential ElGamal:

This alternate scheme, sometimes called exponential ElGamal, is additively homomorphic:

E : (Gq, •)→(Gq x Gq, +)

featuring the + on the right hand side, and should satisfy

E(m1) · E(m2) = E(m1 + m2)

This allows calculating the tally within the ciphertext space by simply multiplying the ciphertexts. Typically[2], the ballot ciphertexts have a vector form, and are multiplied component-wise. For example, imagine there are 4 delegates, and we have six votes, which we represent below as row vectors.

(0 1 0 0)

(0 0 1 0)

(0 1 0 0)

(0 0 1 0)

(1 0 0 0)

(0 1 0 0)

=

(1 3 2 0)

Each component of the above row vectors encrypts the value ‘0’ or ‘1’. These ciphertexts are multiplied together to give the tally result, which is still in encrypted form. The result can then be decrypted without compromising vote secrecy for individual ballots, which are never encrypted.

Going back to the scheme, this tally result after the first ‘+’ operation gives us the Delegate totals, which is still double bordered. The next step is to combine these delegate totals with the publicly expressed votes that the delegates make.

One way to do this would be to simply multiply each delegate choice by that delegate’s weight, which is obtained by decrypting the delegate totals we just obtained. For example, imagine a Yes/No election with our four previous delegates:

Delegate 1: Yes

Delegate 2: No

Delegate 3: No

Delegate 4: Yes

which multiplied by our decrypted delegate totals would give

Delegate 1: 1 x Yes

Delegate 2: 3 x No

Delegate 3: 2 x No

Delegate 4: 0 x Yes

giving a total of

Yes: 1, No: 5

which would then be processed further together with the direct overriding votes.

Instead of the procedure we have followed, the ‘Grouped +’ arrow in the scheme defers decryption to obtain somewhat better privacy for delegate totals. The trick is to group the delegates according to their vote, and apply a homomorphic tally for each group of ciphertexts that correspond to delegates with the same choice. Because that operation occurs in the ciphertext space, less information is leaked as to the totals for each delegate. Let’s see how this works with the same example data above:

Yes: Delegate 1, Delegate 4

No: Delegate 2, Delegate 3

We have two sets of ciphertexts to tally, the delegate totals for 1,4 and for 2,3. Since the delegate total ciphertext was

(1 3 2 0)

We sum components 1 and 4 and 2 and 3, getting

(1, 5)

which we then decrypt. This gives us the ‘Weight for choices’ box in the scheme, single bordered. Note how we’re getting the same result as above, where we decrypted the delegate totals first and got:

Yes: 1, No: 5

but with the new approach we don’t know how many votes each delegate received. We only know that delegate 1 and 4 summing 1, whereas 2 and 3 summing 5, but not more information about them individually. Again, this was because we delayed decryption until the last possible step, and performed more operations in the ciphertext space.

The rest of the scheme follows the same pattern as the Mixnet/Mixnet scheme. At this point we have a partial tally corresponding to the ‘Weight for choices’. We must also take into account those voters that chose to override their delegate’s choice casting a direct vote. These direct encrypted ballots are processed by a mixnet to give us a partial tally corresponding to direct choices. The partial tallies corresponding to weighted delegate votes and direct votes are summed together to give the final tally, which is the election result. Like in Mixnet/Mixnet, we must invalidate duplicates by eliminating from the set of delegate ballots those that correspond to voters who voted directly (this is not shown in the diagram).

In summary, our second scheme supporting liquid democracy again inherits the privacy, and end-to-end verifiability properties of each of its two components, each of which appear in different voting schemes (typically referred to as “based on homomorphic encryption” and “based on mixnets”). There are differences, however. The use of homomorphic tallying for delegate votes yields better privacy for delegate totals, which are somewhat protected given that the weighting tally occurs in the ciphertext space. The exact level of privacy depends on the choices in the election: fewer options result in higher weight privacy, as there will be more delegates grouped into each choice.

On the negative side, the use of a homomorphic tally can result in efficiency problems if the number of delegates is large. If we follow a naive scheme as shown above with ballot vectors we need a number of ciphertexts per ballot that is linear in the number of delegates, which quickly becomes impractical. Additionally, these ballots require zero knowledge proofs of well-formedness whose size can also grow linearly with the number of delegates. These two issues would need to be addressed before this scheme can be used for general cases of liquid democracy with unbounded delegates. One possibility mentioned in [1] is:

We will revisit these considerations when we compare the three schemes at the end of the series.