Skip to content

E-voting cryptography: what it proves, why paper still wins

A Trail of Bits explainer walks the crypto behind verifiable voting — threshold ElGamal, ZK proofs, ElectionGuard — and argues it augments paper ballots rather than replacing them.

Published 4 min read

As US voters go to the polls, Trail of Bits' Fredrik Dahlgren published a clear walkthrough of the cryptography that makes electronic voting verifiable — and an argument for why none of it removes the need for paper. It is worth an hour for anyone who works on threshold or homomorphic encryption, verifiable tallying, or ZK proofs, because election systems are where those primitives meet an adversary who only needs to be wrong once at scale.

The primitives, and what each one buys

The post builds a verifiable scheme from four pieces:

  • Threshold exponential ElGamal. Ballots are encrypted to a public key whose private half is split among N trustees, so a quorum must cooperate to decrypt anything. The scheme's additive homomorphism lets the backend sum the encrypted ballots and decrypt only the final tally — individual votes are never opened.
  • Zero-knowledge proofs. Each client proves its encrypted ballot holds a permitted value (no stuffing a "1,000" where a 0 or 1 belongs), and trustees prove the final decryption was performed correctly. Validity without disclosure is the whole game.
  • Benaloh challenge. A voter can "spoil" an encrypted ballot to audit that the software encrypted what they actually chose, then cast a fresh one. It converts "trust the client" into "test the client."
  • Hash-chained commitments (ElectionGuard). Each ballot commitment chains to the previous one, so altering an earlier ballot breaks the chain and is detectable.

Together these give end-to-end verifiability: a voter can confirm their ballot was recorded, and anyone can check the published tally against the public bulletin board.

Where you'll actually meet this

  • Helios — a protocol for low-stakes, low-coercion elections. The IACR runs its own board elections on it, and, as the post notes, had to rerun its 2025 election after a trustee lost their key share. That's the threshold model's failure mode in one sentence.
  • ElectionGuard — Microsoft's SDK, designed as a cryptographic layer on top of paper-based systems, piloted in College Park, Maryland; Preston, Idaho; and Fulton, Wisconsin.
  • Common Access Card — used for voter authentication in some military overseas-voting setups.

The caveat the title leads with

Dahlgren's point is that cryptography adds verifiability on top of paper; it does not replace the paper. The risk with fully electronic or internet voting is correlated failure: a single software flaw or supply-chain compromise can scale across every jurisdiction running the same stack, and detecting it is hard. Paper gives an independent physical record that doesn't share that software's fate. He leans on the principle of software independence — an undetected error in the software must not be able to change an outcome undetectably — and on the 2018 National Academies finding that "no known technology guarantees the secrecy, security, and verifiability of a marked ballot transmitted over the Internet."

What to take from it

  1. Read it as a model, not a verdict. It's a high-level explainer: no formal security proofs, no implementation detail, and mixnets aren't covered. For depth, go to the Helios and ElectionGuard specifications.
  2. Interrogate the trust assumptions, not the math. The ElGamal and ZK pieces are sound; the risk lives in trustee key management (see IACR's lost share), client integrity (what Benaloh challenges test), and the integrity of the published bulletin board.
  3. Treat "verifiable" and "internet-safe" as different claims. Verifiability is a property you can build; coercion-resistance and secrecy over a network are not solved by the same tools.

For practitioners, the reusable lesson generalizes past elections: end-to-end verifiability lets you detect a compromised client or server without trusting it — but only if someone actually performs the checks, and only if a software-independent fallback exists when the checks fail.

Related stories