The project currently has only one developer: Janis Erdmanis. You can get in touch with me at janiserdmanis@protonmail.ch. I will be happy to chat about whatever may be related to this project.
Many legacy software in cryptography is written in C, C++ and Java, making them an obvious choice for implementing an e-voting system. However, these languages have shown their age in the presence of innovations in code reuse and its deployment, like Rust, Go, Swift, Julia, etc. However, Julia may seem least desirable as it lacks a considerable amount of cryptographic libraries such as CryptoGroups.jl, CryptoSignatiures.jl and HistoryTrees.jl, which would be already been available in Rust and Go from the start.
The reason for choosing Julia can partly be attributed to my familiarity with the language. As a PhD student, I spent the ins and outs of effective Julia codebase management and got addicted to the multiple dispatch and corresponding type system. Objectively speaking, Julia offers everything that a modern language like Rust, Go, and Swift could offer in terms of development speed and deployment of code. But in addition, it does offer great opportunities to experiment with the ability to use a type system for making code more modular, with multiple dispatch and Unicode allowing to make code as lean as possible, closely resembling pseudocodes in the papers. And the worry-free compatibility between platforms and Julia versions is a great plus. For instance, ShuffleProofs.jl was developed using Julia 1.7 as a testing platform; however, with no changes, it works with no issues, also on Julia 1.0, now a 4-year-old version.
In future, though its dynamism of Julia may become less attractive when the protocol is stabilised, targeting mobile will become relevant. However, that is far years ahead until such a problem arises, and development within the Julia community, in a sense, is pushing in that direction with StaticCompiler.jl and BinaryBuilder.jl. Thus, in the meantime, let’s have fun :)
PeaceFounder aims to raise verifiability to a new level by providing conclusive public evidence that elections have happened fairly. To achieve this goal, a zero-knowledge proof of shuffle for encryption shuffle takes a central part of the design to get this evidence. The same proof system has been used in elections before in shuffling votes for re-encryption mixnet voting system pipeline.
A typical re-encryption voting system makes conclusive evidence for election integrity but closes that behind the doors and is available only to auditors with special access. We could place the Estonian election system and other state-wide systems in this category where the Verificatum system has been used. I added another column to see what happens if all evidence in such a system is published. A Helios voting system could fit into this category, providing an explicit "Coerce Me" button.
| Typical re-encryption voting system | Transparent re-encryption voting system | PeaceFounder | |
|---|---|---|---|
| Vote | ElGamal encrypted, signed non-anonymously | Plaintext, signed with a pseudonym | |
| Voting types | Multiple options, referenda; limited to a small number of bits | Multiple options, referenda, cardinal, quadratic, budget, preferential, whistleblowing | |
| Long ballot sharding | A link between shard and voter identity is necessary; anonymisation can happen only within a shard, complex implementation. | Shard is assigned to the voters pseudonym; thus, a link is secret; trivial implementation. | |
| Evidence | ZKP of shuffle and threshold decryption; signed encrypted votes | ZKP of shuffle and decryption; signed plaintext votes | |
| Auditability | Evidence is behind closed doors, and auditors need special access | All evidence is public | All evidence is public |
| Threats to integrity | Auditors who verify evidence conspire with election officials; public key cryptography is broken | Public key cryptography is broken | Public key cryptography is broken |
| Threats to accessibility | If the authentification server is infected, it can make the voting experience artificially harder for voters who may not vote in desired ways (negative vote buying); DDOS attack on the authentification server | DDOS attacks on vote collection server: can be mitigated as a third party can take over vote collection, or votes can be sent over mail; | DDOS attacks on vote collection servers or TOR: can be mitigated as a third party can take over vote collection, or votes can be sent over mail; |
| Threats to anonimity | All internal mixes conspire or are being spied upon; decryption keys have leaked; spyware on the phone. | All outsourced mixes conspire or are being spied upon; decryption keys have leaked; spyware on the phone. | The interested party controls the TOR network; an unlimited number of outsourced mixes conspire or are spied upon; spyware on the phone. |
| Participation privacy | The server knows | Everyone knows | Yes |
| Revoting | Until election ends | Even possible to change the vote at midterm | |
| Coercion resistance | Possible to revote secretly at the pooling station | Coercer sees in the public evidence if the vote has been counted | Revoting possible before the votes are published on the buletin board |
| Time to result | Encrypted votes go through mixes where they generate proof; lastly, threshold decryption is used. Time-consuming ZKP can be delayed and rely on operational security | Encrypted votes go through outsourced mixes but may be inaccessible, which can cause delays; lastly, threshold decryption is used | Votes are instantly available to be run through a counting program |
| Doomsday scenario | Auditors disagree between themselves; decryption parties had lost the secret, and no election result can be announced; a large number of user devices infected with malware manipulate the vote before it's signed (detectable?) | Decryption parties had lost the secret, and no election result could be announced; a large number of user devices infected with malware manipulate the vote before it's signed (detectable?); | A large number of user devices infected with malware manipulate votes before signed (voters can detect this by looking at the bulletin board); |
| Cost/Security | Internally managed mixing parties for a quick result; decryption secret management with multiple internal parties; arrangement of independent auditors; expensive | Decryption secret management with multiple internal parties; | Outsourced mixing; failures recoverable; no secrets to keep => cheap |
The colours green, yellow, and red are relative measures of how well a corresponding property for a voting system is achieved compared to alternatives. Note also that this is a subjective selection of frame and evaluation. For instance, participation privacy may be undesirable when a law obligates citizens to vote, like in Australia or requires them to know who had participated.
A significant risk to the PeaceFounder system is for a briber to ask members to forward their votes through a proxy channel they control. To counter this threat, the bulletin board hides the actual votes, showing only their hashes, and gives voters an option to revote, ensuring both receipt freeness and vote fairness. A sequence number along the vote ensures that only the latest cast vote on the device matters.
This method undermines the confidence of vote buyers and coercers, as it prevents them from ensuring that the votes they've acquired will be counted in the final tally. As a consequence, they can only return bribes after votes are published on the bulletin board. (During the vote, only receipt hashes are published on the bulletin board. This serves to both commit the votes while maintaining fairness and receipt-freeness.) This arrangement erodes the credibility of bribers and coercers, making it less likely for voters to engage with them in such transactions due to the lack of a guaranteed positive/negative outcome.
A secondary concern is the potential for a coercer to ask an individual to show how they had voted on their device. To address this, only a receipt is shown. However, this receipt can be linked to the specific vote on the bulletin board. If coercion becomes a significant threat, the receipt can be visible only briefly, such as 30 minutes after casting a vote. During this window, members can manually record their details in a logbook. While this approach may reduce user-friendliness, it still serves as a robust deterrent against malware.