by Joseph Kiniry and Daniel Zimmerman
A response to criticism of VoteSecure, its limitations, and the security benefits of end-to-end verifiability
In December 2025, Andrew Appel published a critique of VoteSecure. A month later, he and a group of election-security researchers published a broader statement against internet voting. Both posts raise serious questions about VoteSecure, the way it was announced, and whether any internet voting system should be used in a public election.
We discussed the criticism in public GitHub issues, corrected faults that researchers found, and expanded the VoteSecure documentation, but those answers remained scattered. Election officials and members of the public should not have to reconstruct our position from a collection of technical threads, so we want to capture our response here.
The January statement characterizes our GitHub replies as conceding that all the critiques are accurate and that we do not know how to do better. That is not an accurate account of those replies. They identify particular concerns we accept, conclusions we dispute, and requirements that VoteSecure explicitly does not claim to satisfy.
Our position
We disagree with Appel’s conclusion that end-to-end verification adds no useful security, and that VoteSecure leaves a system no better able to detect server-side manipulation than conventional internet voting. Our position on this is that end-to-end verification absolutely adds useful security by making specific forms of ballot manipulation detectable.
A voting system that integrates VoteSecure can let voters use an independent checker on a separate device to check that an encrypted ballot contains their choices before casting it. That checker can expose changes made by a compromised voting application, even when the application displays the choices the voter intended. After casting, voters can confirm that the same encrypted ballot appears in the public record, while public cryptographic proofs let independent observers check the subsequent mixing and decryption.
These checks provide evidence beyond an election server’s assurance that it handled ballots correctly, provided the surrounding system implements the protocol correctly, the checking application and device are trustworthy, and voters and auditors perform the required checks.
Appel’s posts raise concerns about both VoteSecure and internet voting more broadly; our response focuses on the security VoteSecure adds through independent verification, the conditions those protections require, and the specific criticisms of the protocol and SDK.
VoteSecure’s scope
Security claims become muddy when several different things share one name. In our companion article about where VoteSecure fits, we compare it to a car engine. The VoteSecure protocol is the blueprint for that engine, and the software development kit, or SDK, is a working implementation. A vendor must still build the car—the voter application, identity checks, servers, storage, election-official tools, operating procedures, and ways to recover from failures. A jurisdiction must then decide whether that complete system is fit for a particular election.
Here, “VoteSecure” means the protocol and SDK. It is not an application that voters can use or a complete voting system that a jurisdiction can deploy.
Appel’s posts address all four levels. VoteSecure’s launch materials described it as a protocol and SDK, not a complete voting system. We restate that boundary because the criticism moves among the protocol, the SDK, a future product, and a possible deployment.
The announcement accompanying VoteSecure’s launch said that “secure and verifiable mobile voting is within reach,” and quoted our belief that the SDK could meet the standards for the highest levels of certification. Our technical release post described VoteSecure as a protocol and reference library. Both materials distinguished VoteSecure from a complete voting system.
Those statements describe our ambition for the work; the evidence needed to justify deployment must come from evaluating a future complete system that integrates VoteSecure. We chose to work on the underlying machinery because existing remote voting methods need improvement, and any future proposal should begin with open components that researchers can inspect.
The role of verification
The January post argues that the combination of low checking rates and the lack of effective dispute resolution means that end-to-end verification “adds no useful security.” That conclusion is incorrect. In a conventional online voting system, the voter may have no evidence beyond the system’s own statement that it recorded and counted the ballot correctly. A compromised server or election insider may be able to alter the electronic record that the same system later reports. An end-to-end verifiable system publishes cryptographic evidence that voters, parties, researchers, and other independent observers can check.
Detecting server-side manipulation
When a surrounding system correctly implements VoteSecure and the relevant checks are performed, server-side malware cannot silently alter ballots without detection.
A malicious server may disrupt service, withhold information, or attempt to present an inconsistent record, but it cannot change a checked ballot or alter the tally while preserving all of the corresponding public records and cryptographic proofs. This provides independently checkable cryptographic evidence of ballot integrity, giving voters and observers a basis for detecting manipulation beyond the election server’s own account of what happened.
These checks do not have to be performed by the system vendor or the election operator. Political parties, researchers, election observers, and others can build independent tools to examine the same public evidence.
When a voter performs VoteSecure’s checks, the tracking evidence links the ballot the voter examined to the encrypted ballot on the public record. After the election, published cryptographic evidence lets auditors check that the recorded ballots passed through mixing and decryption without alteration. A server that substitutes a checked ballot, or rewrites the public record later, leaves inconsistent evidence. This protection depends on an honest independent checker, a correctly implemented public record, and people performing the required checks.
Checking the voting application
The separate checking device addresses a different threat. If the voting application alone changes a voter’s choices, an honest checker can show the voter what the encrypted ballot actually contains before it is cast. If both devices are compromised, this protection may fail. VoteSecure states that assumption directly. The protocol also makes the voting application commit to an encrypted ballot before the voter decides whether to check or cast it, so the application cannot simply wait to learn which ballots will be inspected.
Why participation matters
A voter who performs the check gains ev dence about that voter’s ballot. Participation determines how much protection checking provides across an election. With no checks, this layer detects nothing. As more voters check, an attacker changing many ballots faces a greater risk that one of the targeted ballots will be checked. The exact protection depends on the checking rate, the attacker’s strategy, the independence of the checking devices, and what happens after a failure. We believe that deeply understanding this protection and its risks and benefits is important for real-world deployment.
Risks and limitations
The verification mechanisms described above address some of the threats discussed in Appel’s posts, but his concerns about their practical effectiveness and the risks they do not address also require a direct response.
Checking requires participation. The protection provided by an optional ballot check depends on voters performing it. A system that makes checking confusing, inaccessible, or uncommon cannot assume that the check will expose a broad attack.
Devices can be compromised. The suggestion that little attention was paid to compromised voter devices does not reflect the published design work or threat analysis behind VoteSecure. The initial concept of operations explicitly assumes sophisticated compromise of voter devices and describes both ballot-alteration and privacy-loss scenarios. “Out of scope” means that the protocol and SDK cannot prevent or remove malware from user-owned hardware, not that the threat was ignored. With a genuinely independent checker, alteration by a compromised voting application can be detected before a ballot is cast. The complete vendor-built applications and system must still address application distribution, checker independence, platform security, authentication, updates, and operational controls. Malware controlling both the voting and checking devices may still deceive the voter, and malware on either device may learn private information that cryptographic verification cannot make secret again.
Availability. Verification can expose certain changes to ballots, but it cannot keep election servers online. A complete system may resist silent manipulation and still be vulnerable to disruption.
Ballot secrecy is not receipt-freeness. A VoteSecure tracking code refers to an encrypted ballot, not a readable vote. Before decryption, trustees shuffle the ballots to break the link between the public encrypted record and the anonymous ballot that emerges. This lets voters and auditors examine public evidence without revealing how an identified voter voted. It does not prevent a voter from showing another person how they voted, and it does not stop someone from pressuring a voter outside a supervised polling place. Remote voting may also let coercion or vote buying operate at a scale different from postal voting. Vote replacement, supervised alternatives, and legal protections may help in a complete system, but VoteSecure itself makes no claim to provide receipt-freeness or coercion resistance.
However, the absence of receipt-freeness does not, by itself, establish Appel’s further claim that VoteSecure enables automated mass vote buying. That conclusion depends on additional assumptions about compromising a cryptographically signed voting application andextracting secret information, producing evidence a buyer will accept, and doing so reliably at scale without detection. We do not view absence of receipt-freeness as an achilles heel: after all, no deployed remote voting mechanism of any kind in the U.S.A. is receipt-free. We simply believe that we need to be honest about the fact that this particular protocol is not receipt-free, just like all other forms of remote voting used today. It is possible to revise the protocol to introduce a receipt-free version, but the research shows that doing so has a significant impact on usability and accessibility. We are open to creating such a variant if there is market demand for that tradeoff.
We chose to work on verification in unsupervised voting environments, where voters may already be observed or pressured, but comparing the risks of different remote methods requires attention to how attacks could scale and which mitigations would work.
A proposed system would need to evaluate measures such as vote replacement and supervised alternatives, and the remaining risk may be unacceptable for a particular election. For example, if an election official believes that voter coercion and vote selling is vanishingly rare in their jurisdiction, they may open for a more usable system, while carrying the risk of not deploying a receipt-free system.
Dispute resolution. A voter may report that a check failed. Election officials then need to decide what evidence is reliable, how to handle an honest mistake or a false report, whether other voters may be affected, and what remedy follows. VoteSecure does not itself specify the complete process for resolving an election-level dispute, and a reusable SDK should not encode one jurisdiction’s election law. That process cannot be purely technical: a deployable system must combine evidence exposed by the protocol with jurisdiction-specific legal and administrative rules, evidentiary standards, and remedies, as existing voting methods do. No such process guarantees the correct resolution of every dispute. But Appel’s categorical assertion that “no appropriate action is possible” is too broad. A voter who sees a mismatch can stop before casting and submit a fresh ballot, and election officials can investigate reports and apply established remedies. The SDK should expose the relevant protocol events and evidence so that a complete system can use them, and any system proposed for deployment must provide a credible process for resolving such disputes.
Findings from public review
On January 13, Vanessa Teague and Olivier Pereira reported a clash attack against the initial VoteSecure release. The attack could let compromised voting applications cause more than one voter to check the same ballot, while changing another voter’s ballot without detection. The advisory classifies the finding as high severity.
We released protocol mitigations for the clash attack in VoteSecure 1.1 on February 6. Florian Moser identified two additional high-severity problems: a malicious voting application could evade an earlier version of the verification process, and a malicious trustee administration server could expose a targeted ballot. The latter two were conditional failures addressed primarily through implementation and procedural checks rather than changes to the underlying cryptographic protocol. The corrections were included in versions 1.1 and 1.1.1, along with updated documentation and threat-model material. No version of VoteSecure has been used in a public election.
Appel’s January post discussed the clash attack soon after it was reported. The published security-advisory record gives the affected and corrected versions for all three findings.
Correcting these findings does not settle the security question. Finding and correcting them before deployment is the purpose of developing VoteSecure in the open: its protocol, implementation, and procedures are published so that independent reviewers can challenge their assumptions and improve them over time. That process should be expected to continue; the findings are neither proof that VoteSecure is secure nor evidence that its underlying approach is unsound.
Continuing the research
Remote voting has divided election-security researchers for more than 25 years. We have encountered that disagreement while evaluating deployed voting systems, building high-assurance election technology, and working with the team that produced the 2015 Future of Voting report. The scientific questions about what can be built are entangled with a practical concern: even early research may be used to justify unsafe deployments.
The response to VoteSecure’s launch illustrates this risk. Although the launch materials distinguished the SDK from a complete system, broad statements about future potential were treated as claims about a deployable product. We will continue tying claims to the version, security property, and evidence being evaluated, and keeping research separate from a decision to deploy.
Appel and the coauthors of the January post expressly say that research on future technology is worth doing. Remote electronic ballot return already exists, and more people are trying to build it. Publishing VoteSecure gives researchers an exact design and implementation to analyze, while giving future system builders an alternative to inventing the cryptographic core in private.
We disagree with treating today’s unresolved problems as a conclusion about every foreseeable technology; useful comparisons must identify the proposed system, its threat model, the available alternatives, and the evidence needed to judge its risks.
VoteSecure’s current status
Cryptographers and security researchers should treat VoteSecure as a public research and engineering artifact whose assurance should continue to grow. Its protocol, implementation, threat model, and advisories are available for review. Further formal analysis, realistic-scale measurements, usability studies, and independent review can make the evidence stronger. No independent body has certified it. Claims about VoteSecure should name the version, the security property, and the evidence being evaluated.
The protocols and algorithms people now rely on for secure communication over the internet also improved over years of public attacks, corrections, and new analysis. Their early usefulness did not end the research; it gave researchers and engineers something concrete to improve. VoteSecure is at a much earlier stage, but we believe the same open process is the responsible way to develop security-critical machinery.
The next steps we see are to strengthen the formal analysis and assurance evidence, measure the implementation at realistic scale, support independent review, study verification behavior, and work with election officials and system designers on the evidence and interfaces needed for credible dispute and recovery processes. We invite Appel, the coauthors of the January post, and the wider community to continue testing VoteSecure against its current code and current claims.
General questions and proposed improvements belong in the VoteSecure repository. Suspected security vulnerabilities should follow our responsible-disclosure process.