As of version 3.1, we plan to support mixnets in Helios. This will enable ranked-voting elections, although we will specifically not attempt to prevent the Italian coercion attack.
Required Changes
- data model support for mixing, multiple stages, storing the results, etc...
- API support for external mixers to read data and update it (signature on data?)
- API support for final decryption in the case of reencryption mixnets.
- workflow modularity so that different election types can be handled using different workflows
- code structure support for modular implementations of each type of election (in particular different mixnets)
- table of mix servers for a given election. Fields: identity of mix server, order in sequence of mixing, proof of mixing, potentially some pre-mixing information for offline/online mixing.
- table of mixed votes, representing the output of each stage of mixing. Fields: output ciphertext, index number in output ordering.
- table of plaintext, decrypted votes, mapping one-to-one to the ordered output of the last mix server.
- table of decryption proofs, one row per decrypted vote and trustee for that election.
- table of "ballot tokens", for ensuring ballot independence in Helios especially with mixnets.
APIs for Mixing and Decrypting
- get-votes-to-mix
- authenticated as the mix server in question
- takes as input election ID and round of mixing
- returns only when the votes are ready for this mix server
- store-mixed-votes
- store a sequence of votes starting with a given offset (as parameter)
- can be used as a single call for < 1000 votes or so, or as a bunch of calls to store them in batches
- each mixed vote is stored in the DB individually
- store-vote-decryption-factor
- store a single trustee's vote decryption factor
- probably doesn't require authentication since the decryption factor should check out, though maybe DoS protection.
It's probably okay to hard-wire the two main classes of workflows: homomorphic and mixnet.
Homomorphic is:
- vote
- compute encrypted tally
- partial decryptions
- combine decryptions and reveal result
Mixnet is:
- vote
- mix stage 1
- mix stage 2
- ...
- partial decryptions of last stage
- combine decryptions for all votes.
Implementation Modularity of Different Mixnets or Homomorphic Tallyings
As much as possible, the algorithms for specific homomorphic verification, combinations, and decryptions, as well as the specific mixnet decryptions and verifications, should be implemented in a modular way so that different teams can work on algorithms for different mechanisms.
In Python and JavaScript, to keep things simple and consistent, each set of algorithms should be defined in a single file / module named according to the name of the variant. For example, for Exponential El-Gamal homomorphic algorithm (the current default one) should be named eeg_homomorphic, and its algorithms defined in eeg_homomorphic.py and eeg_homomorphic.js. The core workflows should be defined in core code, but any algorithm-specific function should be called into the algorithm-specific module.