Hey everyone, Alex here. Welcome back to another edition of Coding with Alex on sysseder.com. Today, we’re stepping away from our usual microservices and Kubernetes setups to talk about a topic that is dominating the news cycle, but with a massive technical twist: election infrastructure.
You’ve probably seen the headlines lately about "America’s Other Elections Problem"—which usually points to the logistical nightmares, aging voting machines, and geopolitical misinformation campaigns threatening the democratic process. But as software engineers, DevOps specialists, and security practitioners, we look at this through a different lens. We see a massive, distributed systems problem. How do you design a system that guarantees complete voter privacy, absolute data integrity, resilience against nation-state actors, and yet remains fully verifiable by the public?
Historically, voting systems have been proprietary "black boxes" running outdated software. But there is a growing movement in the open-source and cryptographic communities to change this. Today, we are going to dive into how we can use modern cryptography—specifically Homomorphic Encryption and Zero-Knowledge Proofs (ZKPs)—to build end-to-end (E2E) verifiable election systems. Let's look at how we can write code to make elections auditable by design.
The Core Challenge of Digital Voting
In traditional system architecture, we rely on the classic CIA triad: Confidentiality, Integrity, and Availability. Usually, we can achieve these with standard databases, TLS, and access control lists. But voting introduces a fundamental paradox that breaks standard database design:
- Anonymity (Privacy): No one should ever be able to link a specific vote back to the voter who cast it.
- Verifiability (Integrity): Every voter must be able to verify that their vote was cast as intended, recorded as cast, and counted as recorded.
In a standard web app, if you want to verify your transaction went through, we show you a receipt with your name and transaction ID. But in an election, if I give you a receipt showing who you voted for, we open the door to voter coercion and vote-buying. Thus, we need a system where you can prove your vote was counted without being able to prove to a third party who you actually voted for.
How do we solve this paradox? Enter ElectionGuard and the world of Homomorphic Encryption.
The Architecture of End-to-End Verifiability
To build a secure, verifiable voting flow, we divide the architecture into three main stages: encryption at the ballot box, homomorphic aggregation, and zero-knowledge decryption. Here is what the conceptual data flow looks like:
+--------------+ Encrypted Ballot +-------------------+
| Voter App | -----------------------> | Election Ledger |
| (Client) | (Zero-Knowledge Proofs) | (Public Database) |
+--------------+ +-------------------+
|
| All Encrypted Ballots
v
+--------------+ Decryption Proofs +-------------------+
| Guardians of | <----------------------- | Homomorphic |
| Private Keys | -----------------------> | Aggregation |
+--------------+ (Partial Decryptions) +-------------------+
|
v
+-------------------+
| Final Tally |
| (Decrypted) |
+---------------------------------------> +-------------------+
Let's break down these stages and write some code to see how they work in practice.
Step 1: Homomorphic Encryption (The Math Behind the Curtain)
In a standard database, if we encrypt our data, we can't do anything with it until we decrypt it. If we wanted to count votes, we would have to decrypt every single ballot, count them up, and hope the person doing the counting is honest.
Homomorphic Encryption (HE) allows us to perform mathematical operations on ciphertexts, producing an encrypted result that, when decrypted, matches the result of operations performed on the plaintexts. Specifically, we use additively homomorphic encryption, such as the Exponential ElGamal cryptosystem.
With additive homomorphic encryption:
Encrypt(A) * Encrypt(B) = Encrypt(A + B)
This means we can multiply all the encrypted ballots together to get an encrypted sum of all votes. We only decrypt the final total, never the individual ballots! Individual voter privacy is perfectly preserved.
Implementing Simple ElGamal in Python
Let’s look at a simplified implementation of how this works using Python. First, we need a large prime group. For production, you'd use safe primes or elliptic curves, but let's illustrate the math:
import random
# Global system parameters (normally very large primes)
p = 2425967623052370772757633156976982469681 # Prime modulus
g = 2 # Generator
def generate_keypair():
# Private key (s)
private_key = random.randint(1, p - 2)
# Public key (h = g^s mod p)
public_key = pow(g, private_key, p)
return private_key, public_key
def encrypt(public_key, message):
# Message must be encoded as g^m (Exponential ElGamal for additive property)
# Let's say message m is 1 (Yes) or 0 (No)
r = random.randint(1, p - 2)
# c1 = g^r mod p
c1 = pow(g, r, p)
# c2 = (g^m * h^r) mod p
g_m = pow(g, message, p)
h_r = pow(public_key, r, p)
c2 = (g_m * h_r) % p
return (c1, c2)
Step 2: Homomorphic Aggregation
Now, let's say we have three voters. Voter 1 votes "Yes" (1), Voter 2 votes "No" (0), and Voter 3 votes "Yes" (1). The total should be 2. Let’s aggregate these encrypted votes without decrypting them:
# Generate system keys
priv_key, pub_key = generate_keypair()
# Encrypt the votes
ballot_1 = encrypt(pub_key, 1) # Yes
ballot_2 = encrypt(pub_key, 0) # No
ballot_3 = encrypt(pub_key, 1) # Yes
# Homomorphic Addition: Multiply the ciphertexts component-wise
# Total C1 = Product of all c1 components
# Total C2 = Product of all c2 components
total_c1 = (ballot_1[0] * ballot_2[0] * ballot_3[0]) % p
total_c2 = (ballot_1[1] * ballot_2[1] * ballot_3[1]) % p
encrypted_tally = (total_c1, total_c2)
Step 3: Decrypting the Tally (And Only the Tally)
We now have the encrypted_tally. When we decrypt this aggregated ciphertext using our private key, we get $g^M$ where $M$ is the sum of the votes. Because $M$ (the total number of voters) is relatively small, we can easily solve the discrete logarithm problem to find $M$ via brute-force or lookup tables.
def decrypt_tally(private_key, encrypted_tally, max_possible_votes=100000):
c1, c2 = encrypted_tally
# s = c1^private_key mod p
s = pow(c1, private_key, p)
# s_inv = modular inverse of s
s_inv = pow(s, p - 2, p)
# g_m = c2 * s_inv mod p
g_m = (c2 * s_inv) % p
# Solve discrete log for small M
for m in range(max_possible_votes):
if pow(g, m, p) == g_m:
return m
raise ValueError("Tally too large or decryption failed")
# Decrypt the accumulated total
decoded_total = decrypt_tally(priv_key, encrypted_tally)
print(f"Decrypted Tally: {decoded_total}") # Output: 2
Think about how incredibly powerful this is. We computed the final sum of the votes while they were entirely encrypted. At no point in this process did we decrypt ballot_1, ballot_2, or ballot_3!
The Developer’s Toolkit: Zero-Knowledge Proofs (ZKPs)
Now, you might be thinking: "What if a malicious voter (or a hacked client application) sends an encrypted value of 100 instead of 1 or 0?"
If they do that, the homomorphic multiplication will still work, and they will effectively cast 100 votes, completely breaking the election. We need a way for the voter's device to prove that the encrypted ballot contains either a 0 or a 1, without revealing which one it is.
This is where Zero-Knowledge Proofs (ZKPs), specifically Chaum-Pedersen proofs, come in. When the voter submits their encrypted ballot, their device generates a cryptographic proof of validity. The voting server verifies this proof before accepting the ballot onto the public ledger. If the proof is invalid, the ballot is instantly rejected.
Verifying Elections via Public Ledgers
Because the ballots are encrypted and accompanied by mathematical proofs, we don't need to hide them in a database. In fact, we want to publish them.
Modern verifiable election systems publish all encrypted ballots, proofs of validity, and the homomorphic aggregation steps to a public, append-only ledger (similar to a blockchain or a git repository with signed commits). Anyone—political parties, independent auditors, or even you on your home laptop—can download this ledger, run the verification math, and independently prove that the announced tally is mathematically correct.
How We Can Push This Forward
If you're interested in building or contributing to these types of systems, you don't have to start from scratch. Microsoft’s ElectionGuard is an open-source SDK written in Python, C++, and C# that implements these exact specifications. It is designed to be integrated into existing voting machines and voting software to provide end-to-end verifiability.
As developers, we have a unique responsibility. Technology can easily be used to centralize power or obscure processes, but with the right cryptographic primitives, we can build open, decentralized systems that guarantee security and transparency at scale.
What Do You Think?
End-to-end verifiable voting is a fascinating intersection of cryptography, distributed systems, and real-world logistics. Do you think homomorphic encryption is the key to securing future elections, or do you think the physical paper ballot remains the gold standard of trust? Have you worked with libraries like ElectionGuard or implemented ZKPs in your own projects?
Let me know in the comments below! And if you found this deep dive valuable, don’t forget to subscribe to the newsletter for more architectural breakdowns, security deep-dives, and dev tutorials.
Until next time, keep your systems secure and your code clean!