,
12 tweets,
4 min read
Read on Twitter
So @SarahJamieLewis, @VTeagueAus and Olivier Periera have found a critical vulnerability in the @swisspost cryptographic voting system. In the worst case, it allows for massive and centralized election fraud. people.eng.unimelb.edu.au/vjteague/Swiss…
The problem occurs because the voting system implements a series of sophisticated cryptographic zero-knowledge proofs, in order to keep votes encrypted and untraceable while also preserving election integrity. At a critical place, one of the proofs is flawed.
Specifically, each voter sends their ballots in to a server in an encrypted form. The server later decrypts and tallies them. In between these two stages, to preserve privacy, a series of servers “mixes” the votes by re-encrypting and shuffling them.
This mix/shuffle step poses a problem. Because the shuffled ballots are re-encrypted in an unrecognizable form, a malicious server could (hypothetically) replace all of the real ballots with invented ones that elect any candidate of their choosing.
The @swisspost system deals with this by using a zero-knowledge proof that the shuffle was correct, and no votes were replaced. Unfortunately they got the implementation of this (Bayer-Groth) proof badly wrong.
What @VTeagueAus, @SarahJamieLewis and Olivier noticed was that the BG proof uses a Pedersen commitment scheme. Most people know that Pedersen commitments rely on a set of “bases” that have to be generated in a trustworthy way: you can’t know a relationship between them.
The designers of the @swisspost system somehow did not realize this. They instead generated those critical parameters fresh with each ZK proof the system makes. This undermines the soundness of the proof system.
In the extreme case (which takes a few other conditions, like a flaw elsewhere in the JavaScript client) this could allow a single mix server to replace every ballot it sees with a new ballot. Such an attack would be hard to detect.
Even worse, this stolen election would be “end to end verifiable” thanks to the appearance of valid ZK proofs. Good luck disputing “math”.
The @swisspost folks are going to write this off as a “bug” and a successful result of their bug bounty program. But don’t let that fool you. This is the equivalent of installing the shock absorbers backwards when you’re building a nuclear plant on top of the San Andreas fault.
This is not a question of substituting an “==“ for an “=“. There are relatively few bugs that can (1) totally compromise an e2e verifiable election *and* (2) demonstrate that the designers don’t understand the cryptographic tools they’re working with. This bug does both.
@SarahJamieLewis has been pointing the poor code quality out from the day she started looking at the code a few weeks ago. That in just that short time, she and @VTeagueAus and Olivier were able to complete break the system — not a coincidence.
