How to get in touch?

The project currently does have 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.

Why Julia?

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 allowing to write code faster by providing tools for code reuse and its deployment like Rust, Go, Swift, etc, where a considerable amount of cryptographic libraries is already available. Thus Julia may seem an odd choice for such a project as an e-voting system.

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 would rise, 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 :)

How does PeaceFounder compare with XYZ?

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 Possible to revote secretly at the pooling station
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.

How does the PeaceFounder system protect against vote selling and coercion?

Coercion resistance can be implemented by allowing voters to revote and keep it a secret that they have done so. When counting the votes, those who have devoted their public votes can be subtracted at the pooling station, which has accepted a vote. It's also possible to do this remotely and add different cross-accountability mechanisms, but now that is out of the scope of the PeaceFounder project. Also, to do that properly, one would need to add hardware so that coercers could not extract voters secret keys.

An alternative way to look at coercion resistance is through a way an individual could protect his/her voters privacy. The ability to whistleblow anonymously in case one offers to buy a vote or has heard about that from a friend could enable easier investigation. Sharding of long ballots can prevent the briber from reaching the key voters who decide on a sensitive question. Also, voting more often could make life more inconvenient for coercers, and bribers as a single ballot would have less stake in it.