A Secure electronic voting system (version 2)

** Updated 20th July 2025

This is version 2 of an earlier post

Temporal stages of the whole election

Ill start by first going over the 6 sequential phases during which the election takes place, and a winner is announced:

1. Before registration

   All services are unavailable, other than information on where/when to register.

2. Registration

   All voters must register to vote, providing identity credentials and in return receiving a set of single use keys to authorize the vote.

3. Redistribution/shuffle (A)

   There are two resdistribution/shuffle stages, and each of them roughly conist of three sub-stages a) Anonymising - This means hashing and encrypting all information sent by individual voters.

   b) Shuffling - Randomly shuffling the association between who the voter is and who the vote is for.

   c) Restributing - Randomly distributing the data across different physical servers.

4. Voting

   All registered voters uses the credentials they obtained in stage 2 in addition to further credentials in a highly specific, verbose, and deliberately fragile protocol to cast their vote for their chose candidate

5. Redistribution/shuffle (B)

6. Counting and Sorting

   • Votes are counted across multiple distributed servers and the results are collected. The results are not collected and sorted, but rather a consensus is reached across all servers and the winner is decided through an election leadership protocol.
   • Individual votes are then published so the result can be publicly verified.

System Architecture

The proposed system architecture for this electronic voting system is shown in the diagram above. As you can hopefully see, its not that complicated. This diagram is a pretty big simplification, and doesnt include quite a few infrastructure features such as private subnets, and it also doesnt show the flow of data and order of events/protocols, but I think its a good starting point. Anyway, its not like I even know the complete picture myself, but some key points to note from this diagram are:

• This a web based system, and so does not rely on dedicated voting machines.

• There are two ‘groups’ of servers, the registration servers and the voting servers. There are at least 3 registration servers and 1 voting server

• Each group is scalable individually, so there are potentially thousands of registration servers, and a similar (but not necessarilly the same) number of voting servers.

• Similar to MFA, The client performs the registration protocol by interfacing with all available (at least 3) registration servers.

Protocols

Ok, so now lets go through each of the temporal stages individually and illustrate (with the help of diagrams of course) the protocol(s) involved at each stage.

Before Registration.

Nothing much to say here, everything is closed, any attempt to register or vote will error with instructions on how to register and what documents are required.

Registration

As I mentioned above, the registration protocol actually takes place with the client interfacing with a sequence of n registration servers (where n >= 3). Lets call these three registration servers $RS_1,RS_2, RS_3$

The registration protocol sequence

The registration protocol sequence works somewhat like this.

Before any network requests, the client ($C$) generates n random keys, where n is the number of registration servers in the protocol sequence, in the case $n = 3$. One of these keys is chosen to be ‘real’ and the rest are decoys, but the client alone keeps track of which is which. Call these: $Ҝ_1, Ҝ_2, Ҝ_3$

1. The client receives in the physical post their polling card as they usually would do, a password ($p_1$) (similar to the letter the bank sends you with your pin when you order a new bank card), and the hostname of the registration server which sent them this letter and in response they send:

a) to $RS_1$:

• $p_1$ (the password they just received in the post)
• A hash of a randomly generated nonce $hash(n_1)$
• Photos of documents verifying their identity such as a selfie, their passport, and a proof of address
• Its own identity $C_identity$
• One of its generated keys ($Ҝ_1$)

b) to $RS_2$:

• $hostname(R_1)$
• $n_1$
• Another one of its generated keys $Ҝ_2$

b) to $RS_3$:

• $hostname(RS_1)$
• $n_1$
• The third generated keys $Ҝ_3$

1. Both $RS_2$ and $RS_3$ then contact $RS_1$ with
   • $C_identity$
   • $n_1$

When $RS_1$ then receives these two requests, it checks to see if the hash of the received $n_1$ is the same as the value received in step 1a). If it is for both requests, and the same identity was requested from both $RS_2$ and $RS_3$, tand the $C_identity$ physical human identity was also successfully verified previously, then $RS_1$ responds with a simple success message.

1. At this point, $RS_1 RS_2, RS_3$ are all on the same page and the client has succesfully registered. So, at this point each registration server store appends to a private internal data structure a mapping from ($C_identity$ -> $hash(K_i)$), where $K_i$ is the randomly generated key it received in stage 1.

Shuffle redistribution (a)

1. The private data structures are physically extracted from each of the n registration servers and manually escorted by a convoy of armed vehicle to the voting servers. The mapping that decides which registration server transfers their hard drive to which voting server is distributed randomised and to the extent that no single person or server has full knowledge of the complete mapping.

Voting

The group of authentication servers form a distributed hash map, and 1/3 of records from each of their internal data stuctures are duplicated and distributed across some of the other voting servers.

1. Now the votes start to come in, and a single vote is made up of $n$ network requests, (remember, in this case $n = 3$):

a) to any randomly chosen voting server:

• $C_identity$
• ($vote_1$, $Ҝ_1$)

b) to any other randomly chosen voting server:

• $C_identity$
• ($vote_2$, $K_2$)

c) to any other randomly chosen voting server:

• $C_identity$
• ($vote_3$, $K_3$)

Where (for example) the ‘real’ key is $Ҝ_1$, and the clients ‘real’ vote is $vote_1$, the client knows which is their real key and their fake key, and so sends the real key with their ‘real’ vote (i.e the candidate they actually want to vote for), and their decoy key with a fake vote (i.e any other candidate)

1. Either of the network requests can be directed at any of the voting servers, as all voting servers together form a ring via the CHORD protocol, and because the ($C_identity$ -> $hash(K_i)$) mappings are duplicated and randomly distributed, on any voting server receiving a vote request, it performs the following steps:

2. Checks if it has a record for the received $C_identity$, if it does, it calculates the hash of the key in the voring request and if that matches.

0.s which voting servers has a record for (b) and forwards the original request at this server using the CHORD protocol. If no entry for $C_identity$ is found, an error response is returned to the client.

c) The server checks if the nonce received