RemoteVote and SAFE Vote: Towards Usable End-to-End Verification for Vote-by-Mail

by   Braden L. Crimmins, et al.

Postal voting is growing rapidly in the U.S., with 43 ballots by mail in 2020, yet until recently there has been little research about extending the protections of end-to-end verifiable (E2E-V) election schemes to vote-by-mail contexts. The first - and to date, only - framework to focus on this setting is STROBE, which has important usability limitations. In this work, we present two approaches, RemoteVote and SAFE Vote, that allow mail-in voters to benefit from E2E-V without changing the voter experience for those who choose not to participate in verification. To evaluate these systems and compare them with STROBE, we consider an expansive set of properties, including novel attributes of usability and verifiability, several of which have applicability beyond vote-by-mail contexts. We hope that our work will help catalyze further progress towards universal applicability of E2E-V for real-world elections.



There are no comments yet.


page 1

page 2

page 3

page 4


Voting Framework for Distributed Real-Time Ethernet based Dependable and Safe Systems

In many industrial sectors such as factory automation and process contro...

Electryo, In-person Voting with Transparent Voter Verifiability and Eligibility Verifiability

Selene is an e-voting protocol that allows voters to directly check thei...

A case study in formal verification of a Java program

We describe a successful attempt to formally verify a simple genetic alg...

The Snowden Phone: A Comparative Survey of Secure Instant Messaging Mobile Applications (authors' version)

In recent years, it has come to attention that governments have been doi...

The Making of 5G: Building an End-to-End 5G-Enabled System

This article documents one of the world's first standards-compliant pre-...

BrFAST: a Tool to Select Browser Fingerprinting Attributes for Web Authentication According to a Usability-Security Trade-off

In this demonstration, we put ourselves in the place of a website manage...

Content Generation for Workforce Training

Efficient workforce training is needed in today's world in which technol...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

In the 2020 U.S. presidential election, 43% of voters cast their ballot by mail, twice as many as four years prior [census]. While driven largely by the COVID-19 pandemic, this increase follows on a long-term trend towards greater use of vote by mail [electionlab]. At least 34 states have adopted policies allowing any voter to participate by mail with no excuse, and seven of these states automatically send a mail-in ballot to every voter [ncsl20vbm]. These changes make voting by mail a fundamental part of U.S. election administration, and one that is essential to secure. Indeed, corrupting only vote-by-mail ballots would likely have allowed outcome-changing fraud in every U.S. presidential election since the turn of the century.

While end-to-end verifiable voting systems (e.g., [helios, remotegrity, selene, civitas]) show promise for assuring election integrity, most E2E-V schemes are intended for online or in-person voting and cannot easily be adapted to secure votes cast by mail. In fact, until the recent introduction of STROBE Voting by Benaloh [strobe], vote by mail (VbM) systems were almost entirely absent from the verifiable voting literature.111Remotegrity [remotegrity], which is sometimes cited as a vote-by-mail election system, relies on voters casting their ballots over the Internet after receiving them in the mail.

We introduce two novel E2E-V systems, RemoteVote and SAFE Vote, that are designed to enable end-to-end verifiable U.S.-style postal voting while improving on aspects of usability and other desirable properties compared to STROBE. To evaluate our schemes and earlier VbM E2E-V proposals, we consider an expansive set of properties, including novel attributes of usability and verifiability. Several of these properties have applicability to systems outside of a VbM context. Lastly, we present a hybrid system that combines ideas from our two schemes and provides more of these properties than any other design known to the authors, although this comes at the expense of reduced practicality. We hope our work will advance the state of knowledge about E2E-V closer to systems that are suitable for deployment in real vote-by-mail elections.

2 Related Work: STROBE

STROBE Voting [strobe] is a significant step towards achieving verifiable VbM, and identifies the primary difficulty of designing such a system: the unique limitations on communication between the voter and the election authority.

Many verifiable voting systems rely on the Benaloh challenge [benaloh-challenge, marky-usability], a type of interactive proof that a voter can perform to check the honesty of the encrypting authority. This is an effective solution for in-person or even Internet voting, because the voter can perform the interactive step and receive a response immediately. In VbM contexts, however, the only private communication channel between the voter and the election authority is the extremely-high-latency postal system, which imposes a difficult constraint on any kind of interactive challenge.

Nevertheless, STROBE proposes an interactive procedure that is suitable for VbM settings. First, the election authority precomputes multiple encryptions to be sent to the voter and communicates them through the initial ballot delivery. Then, the voter chooses a set of encryptions to use and communicates this choice through the return of their voted ballot. The authority completes the challenge process by posting the decryptions of all spoiled ballots to a public bulletin board.

This design represents a significant advance towards achieving verifiable VbM elections. Even still, as Benaloh acknowledges, there are some important practical drawbacks; in its basic form, for example, STROBE requires that each voter be sent two ballots and only be permitted to cast one. Several concerns are immediately apparent, such as the added printing and mailing costs and the potential for distrust or confusion when voters receive multiple ballots.222See, for example, the confusion that occurred when voters were sent multiple absentee ballot applications in many U.S. jurisdictions before the 2020 election [multiple_applications, abc_applications]

Other concerns are more subtle. Suppose, for example, that a cache of ballots are returned but not processed, and the encryptions are spoiled before the mistake is discovered.333A similar error occurred in Georgia during the 2020 presidential election. [georgia-ap] Those voters lose either their privacy or their ability to validate the election outcome. Alternately, suppose both ballots in a twin set are cast. What recourse exists? This might occur due to attempted fraud by the voter, but it could equally well be the result of a misunderstanding of the system. Even if the system isn’t misunderstood, it could still be an innocent mistake; for example, two members of a household might accidentally vote both ballots belonging to one of their sets and neither ballot belonging to the other. Counting both ballots would produce false evidence of fraud, because any observer could see that two twin ballots were both returned and counted. Failing to count both ballots disenfranchises one of the two voters. Neither outcome is desirable.

The STROBE paper also proposes an alternative implementation that resolves these concerns by representing two sets of encryptions on a single physical ballot, but this introduces problems of its own. For example, because the ballot is returned before the spoil process occurs, a corrupt election authority would have custody of all evidence of their own malfeasance at the time it is revealed. Another concern comes from deciding which set of encryptions should be used; implicit mechanisms for choosing a column to spoil can be easily forged or manipulated by a corrupt authority, while explicit mechanisms leak information about who has participated in verification, which could facilitate targeted cheating in subsequent elections.

The ideas underlying STROBE are strong, and indeed a modified version forms the basis of one of our proposals, but further advances will be required for any E2E-V system to be usable in real VbM elections. We hope that the two schemes we propose represent progress in that direction.

3 Desirable Properties

To evaluate our proposed schemes and compare them to existing designs, we introduce a set of desirable properties, ranging from attributes of the verification procedures to aspects of usability. Properties that are novel (to our knowledge) are bolded and italicized when first introduced.

3.1 End-to-End Verifiability

A common goal of election system design is to create a system which is end-to-end verifiable. Such a system seeks to provide public guarantees that the election result is accurate without relying on trust in the administering authorities. There are three main subproperties that an E2E-V system must have [Benaloh2015EndtoendV]:

Cast as Intended

means that a voter can be confident their choices were accurately received by the election authority.

Counted as Cast

means any observer can be confident that all choices received by the election authority were tallied correctly in the final result. (This is sometimes split into collected-as-cast and counted-as-collected [bernhard2017public].)

Eligibility Verifiability

means observers can verify that only eligible votes were included in the tally [bernhard2017public], preventing threats like ballot box stuffing and multiple-voting. Many jurisdictions provide this property to some degree through the publication of a post-election list identifying all those who cast a ballot. This allows observers to validate that the number of votes is equal to the number of voters and (at least in principle) that all voters were eligible.444Because it is primarily accomplished by procedural controls rather than cryptographic ones, and because we can largely rely on existing solutions to achieve it, this property is often ignored in the E2E-V literature. It is necessary to prevent fraudulent election results, however, so we consider it fundamental for the purpose of our definition.

When considering claims of verifiability, it is similarly important to understand who can actually perform the verification for each element of the system.

Universal Verifiability

means that any observer can single-handedly verify the property across the entire election [framework]. Typically, counted-as-cast and eligibility verifiability are universally verifiable in E2E-V designs.

Individual Verifiability

means that a voter can verify the correct behavior occurred for their own ballot [framework]. Typically, cast-as-intended is individually verifiable in E2E-V designs. Mechanisms for universal cast-as-intended exist [universal-cit], but those are beyond the scope of this paper.

Collective Verifiability

means that voters can collaborate with each other to verify that the correct behavior occurred for all their ballots. Consider a design in which a voter can gain a certain level of confidence (e.g., 50%) that the system is honest, but cannot individually increase their confidence beyond that level. By collaborating with other mutually-trusting voters, each of whom independently have their own partial confidences, these voters can together confirm the honesty of the system to arbitrary confidence.

3.2 Privacy Properties

Another key goal of election system design is to ensure voter privacy. What precisely “privacy” means, however, depends heavily on the threat model, giving rise to a series of properties intended to address different threats.

Ballot Secrecy

means that a system does not leak information about voters’ choices beyond that which can be deduced from the election’s result [bernhard2017public].

Receipt Freeness

further means a voter cannot prove their choice to a third party, even if the voter actively attempts to aid in the construction of such a proof. This has historically been intended as a defense against vote buying [bernhard2017public].

Everlasting Privacy

means that a system does not rely on assumptions about cryptographic hardness to provide the two preceding properties. If we do rely on such assumptions, a weakness in the encryption systems used—even if discovered decades later—could reveal voters’ choices in previous elections [everlasting]. We further use the more nuanced terms everlasting ballot secrecy and everlasting receipt freeness to reason about systems that might only provide one of the two traits if cryptographic hardness assumptions fail.

Coercion Resistance

means the system ensures no voter can be compelled to exhibit certain voting behavior. Complete definitions entertain not only forcing a voter to choose a favored candidate, but also forcing them to abstain or to randomize their ballot, which would enable targeted disenfranchisement [bernhard2017public].

3.3 Usability Properties

The importance of usability is well recognized in voting system design, and past failures on this front have had enormous consequences.555See, for example, the usability failures of “butterfly ballot” punch card systems, which some believe altered the outcome of the 2000 U.S. presidential election [chads]. Nevertheless, usability has not been formalized in the same way as other E2E-V properties. Here we aim to define aspects of usability that can be used to discuss and compare systems, albeit with some room for subjective interpretation.


means that a voter can ignore the novel elements of the system and “vote like normal” without compromising the integrity or privacy of their vote; they simply will not be a participant in the verification process.


more strongly means that a voter cannot compromise the integrity or privacy of their vote even if they engage improperly with the system’s novel elements. It should not be possible, for example, to inadvertently spoil a ballot by making a mistake involving the verification features.

Selection Consistency

means that a voter’s selections on their ballot will be directly reflected by the evidence that their vote was cast-as-intended, for example in a shortcode receipt that corresponds directly to the markings they made. This property aims to prevent illusory discrepancies, like those that might arise when a ballot is processed before the evidence is generated, which might otherwise create the appearance of fraud where none exists.666For example, in a jurisdiction which permits straight-ticket voting with contest-specific overrides, the voter may expect to see a commitment to the selections they made, while a homomorphic-tallying election system would instead generate a commitment to the interpreted result of those selections after the straight-ticket rule was applied.

3.4 Error Handling Properties

Many election systems are premised, either implicitly or explicitly, on assuming the election was error-free and designing proofs that convince observers of that fact. It is equally important, however, to entertain the possibility that errors might occur and consider how the system might handle them. The following three properties deal with identifying and addressing these errors if they occur.

Software Independence

means that an undetected error in election software or hardware cannot create an undetectable error in the election’s outcome [rivest16si]. This means that no malicious software can alter the outcome undetected when there exists a dedicated and trustworthy observer.

Strong Software Independence

additionally means that when such an error is discovered, the true result can be recovered without rerunning the election [rivest16si], for instance by hand-counting the original paper ballots.

Dispute Resolution

means that if a voter accuses an authority of dishonesty, a third party can unambiguously determine whether or not it is true [disputeresolution]. An important subproperty is collection accountability, which means a voter can prove it if the authority misrepresents their choice in the public tally [bernhard2017public].

3.5 Verification Process Properties

The property of verification does not arise in isolation; it arises out of a series of checks that have properties and side effects of their own. These properties have substantial implications for the reliability of the system in application.

Advance Verification

means that all verification mechanisms can be exercised before the election results are computed. This helps to remove some improper incentives; if an individual must allege fraud before they learn the favorability of the outcome, the political motivation to make false reports is decreased.

Discretionary Verification

means that voters are able to choose at will which elements of the system they would like to verify. This eliminates reliance on external decisional systems and allows voters to trust only their own agency. If voters are able to select arbitrary ballots to challenge for a given audit procedure, this is an example of discretionary verification. If instead the ballots are selected by some other process—for example at random, even through some publicly accountable mechanism—the property is lost.

Independent Verification

means that the verification mechanism can be used by an individual voter or observer without participation from the system itself. This forestalls attacks in which a cheating authority feigns inability to cooperate with the challenge process (e.g., by pretending a DDoS attack is preventing voters from logging challenge requests on a public bulletin board). It also reduces the risk due to real logistical problems on election day.

Unobservable Verification

means that no adversary can become convinced that a given individual abstained from the verification process. If the adversary is able to learn who abstains, and monitors this behavior over several elections, they can target later ballot manipulation toward those who are least likely to detect that fraud occurred. Note that the adversary can learn the identities of some of those who engage in the challenge process, but not the identities of everyone who does, since that would reveal exactly who does not participate.

3.6 Compatibility Properties

E2E-V schemes vary in what modes of voting and counting methods they are suitable for. We consider two aspects of such compatibility:

Vote-by-Mail Compatibility

means that a system is able to provide its claimed security properties to voters whose only private communication channel with the election authority is postal mail, although such voters are assumed to also have access to publicly broadcast information.

Complexity Tolerance

means that a system enables arbitrary computations on anonymized vote data without compromising security guarantees. Systems with this property can implement any computable tallying system, such as Instant Runoff Voting. Implementations without this property, including homomorphic systems, are limited in what voting methods they can support.

(a) RemoteVote
(b) SAFE Vote
Figure 1: Ballot designs for our two proposed schemes.

4 Our Proposed Schemes

Our schemes use a similar approach to STROBE [strobe]. At a high level, every voter is given a ballot with a unique ID and seemingly random shortcodes beside each candidate. When voting, they can record this ID and the shortcodes corresponding with their choices. The authority posts this same information to a public bulletin board for every ballot they collect, and voters can confirm this “receipt” matches what they recorded to be confident their votes were counted correctly.

There are similarities behind the scenes, too. As with STROBE, we use ElGamal threshold encoding to create a homomorphic encryption for each choice available to the voter.777Like STROBE, we include abstentions and undervotes within the meaning of “choice.” For this reason, in a contest where the voter can select candidates, we produce encryptions representing abstentions in addition to the ones representing selected candidates. This way, all choices—including abstentions and undervotes—can be represented as the sum of encryptions, and are therefore indistinguishable. We also generate a shortcode for each candidate that commits to the encryption, such that the mapping between codes and candidates is only known to the voter, but the published shortcode receipt can be used by observers to verify the election tally. Lastly, we generate a single longcode that commits to the encryptions without revealing the candidates they correspond to.

We also introduce a series of departures and enhancements compared to the STROBE framework. First, when we tally votes for a contest, we do it in a two-stage process. We begin by homomorphically tallying each individual voter’s choices within the contest to generate a single encryption per ballot cast. We then run these encryptions through a verifiable anonymizing mixnet (e.g., [shuffling, mixnet]) then decrypt and process them in the clear. This means we can represent candidates with a single binary flag each, denoting either that they were selected or were not. There’s also no need for STROBE’s non-interactive zero knowledge proofs that each encryption contains a valid vote; any issues will be recognized when the decryption process occurs, and can affect at most a single voter. The ordinary challenge process suffices to address this risk. A final advantage is that this approach enables selection consistency and complexity tolerance; because we process the data in the clear, we support arbitrary computation on voters’ anonymized choices, and therefore support arbitrary tallying mechanisms. STROBE, by contrast, relies on homomorphism to compute the result, which means it cannot support voting systems that use more complicated tallying systems and cannot always directly represent a voter’s selections in the published shortcode receipts.

Second, when we generate our encryptions, we use the same random value to seed ElGamal for every encryption on a given ballot.888We can alternately use as a seed for a PRNG, to allow different ElGamal seeds. This way, can be used to reconstruct the entire ballot’s set of encryptions. This is not strictly a difference from STROBE, as the original paper does not specify one way or another, but it is important for SAFE Vote, so we specify it explicitly.

Third, we do not directly reveal the encryptions involved in our system to the public. Instead, we derive perfectly hiding commitments to these encryptions via the PPATS mechanism introduced in [cce] and further elaborated on in [everlasting]. This system is an example of a commitment consistent encryption (CCE) scheme, which allows the creation of commitments that can be used as a one-to-one stand-in for encryptions in a homomorphic tally or mixnet, then can be “opened” to the underlying encryption value once they are tallied or anonymized. These commitments offer information theoretic privacy [everlasting], which means the privacy properties remain even if all modern cryptographic assumptions fail. We generate these commitments immediately after generating our encryptions, and use them—rather than the encryptions themselves—to form the basis for our shortcodes and ballot IDs. The only modification we need to make to account for this is that after the mixnet step in our tallying, we open the commitments to the underlying encryptions before we can decrypt; everything else operates identically.999Using CCEs to implement both a homomorphic and mixnet tallying step is usually infeasible for large-scale elections [cce]. Because the format of possible votes is highly predictable, however, an exhaustive search of plaintexts is easy, and decryption becomes cheap enough that we can use the PPATS system for both. Note that each commitment requires 256 bits of true randomness to generate, which is retained privately by the election authority for use in the tallying process.

Fourth, and lastly, we commit to each encrypted ballot in advance of the election. This means posting the commitments, shortcodes, and ballot ID of each ballot when it is first generated.101010Alternately, we can just post the commitments (since they can be used to derive the rest of the information), but posting everything makes the process easier for observers. As with using the same value for all ElGamal seeds on a ballot, this is not strictly a difference from STROBE, as this commitment is still possible in the original design. It is important for our auditing process in RemoteVote, however, and so is important to specify here.

4.1 RemoteVote

RemoteVote ballots look identical to those of single-ballot STROBE (see Figure 0(a)), but the challenge process is markedly different. Where STROBE attempts to facilitate an interactive challenge through limited communication channels, RemoteVote abandons the idea of interactivity altogether.

This means we sacrifice discretionary auditing, but in exchange we gain a number of other valuable properties. Notably, we can perform the challenge process when voters still have custody of the ballots, giving a greater degree of dispute resolution. There’s also no way for the authority to be confident any voter abstained from this process, giving unobservable verifiability. Recall too that in single-ballot STROBE, the election authority could simply ignore the preference of the voter and spoil whichever column they want. In our design, this is no longer the case; compliance with the spoiling procedure is universally verifiable.

To implement this scheme, we begin by pairing encrypted ballots.111111Pairs should be constructed such that there is no shortcode collision within a contest. We commit to these pairings by posting them to a public bulletin board and generating a single combined ID from their two longcodes. The paired set is printed on a single physical ballot such that there are two columns of shortcodes beside the candidates’ names, one column corresponding to each encrypted ballot. The ballot ID is printed at the bottom of each ballot in human-readable format.

After the ballots are delivered to voters, randomness is generated in a publicly accountable manner (e.g., [rla]) and used to deterministically select one column to spoil for each ballot.121212

One effective heuristic would be hashing the randomness with the ballot ID and selecting a column based on the resulting hash’s parity.

The secret information for that column’s encrypted ballot is posted publicly alongside all the rest of the ballot pair’s public information, where it can be accessed at will by third parties. These observers can then validate that the column’s encryptions and commitments were all well formed.

With the newly public information, a voter can apply a trusted third-party system to generate a partial image for their ballot based on its ID. This image would display one column of expected shortcodes next to the appropriate candidates, and by validating this against the ballot they were sent, the voter can be sure that the spoiled column of shortcodes represented an accurate set of encryptions. Provided they trust the public randomness, a voter would know that a forged encryption on their ballot would have had a 50% chance of being revealed.131313Even if they don’t trust the entire public randomness, a voter can have confidence in this system; only one in possible pairings would be fully resistant to detection, where is the number of trustworthy bits. Validating that a particular pairing belongs to that set would require computing hashes if the challenge heuristic uses a secure hash function. This means that an attack on encryption integrity is computationally infeasible for any meaningful number of trustworthy random bits. This provides collective verifiability, because many audits at 50% confidence quickly scale to ensure any large-scale fraud would be detected.

The voter can then vote like normal (ignorability and harmlessness), return their ballot, and optionally watch that one of the two shortcodes beside each selected candidate appears for the proper contest; whether that shortcode is from the correct column can be validated by anyone else, because the spoiling of the challenged column is universally verifiable.

4.2 SAFE Vote

Scratch Auditing for Fair Elections (SAFE) Vote is an alternate approach that attempts to preserve the interactivity of the challenge process while resolving some of STROBE’s other issues. We accomplish this by including a physical challenge mechanism on each ballot that we send to voters. This maintains discretionary auditing, but also incorporates independent auditing and ensures the challenge process provides immediate evidence as to whether or not a discrepancy was uncovered. Like RemoteVote, this occurs when the ballot is still in the voter’s custody, giving dispute resolution through physical evidence of potential fraud.

SAFE Vote ballots (see Figure 0(b)) contain four special features. First, each option has a single corresponding shortcode printed beside it. Second, the longcode is printed as the ballot ID. Third, the value of is printed on the ballot and concealed by a scratch-off surface. Fourth and finally, the ballot includes a large QR code, which, when decrypted using as the key, provides the true randomness used to generate the ballot’s commitments.141414Recall that 256 bits of true randomness are necessary per commitment.

These modifications can be ignored by voters who do not choose to participate in the verification process, but they enable voters to independently audit the ballot’s encryptions if they desire. To do so, voters would remove the scratch-off surface, revealing . Trusted third-party software can use this value along with the QR code to reproduce the ballot’s shortcodes and ID in full, and the voter can compare the output against the ballot they were sent. If there are no inconsistencies, voters can be confident that their ballot was correctly encrypted. They can then request a replacement and repeat the challenge as many times as they like, until they eventually trust the encryptions and cast a ballot.151515Voters may also simply request multiple ballots up-front, if policy permits.

Ballots received in this system should be processed just as with STROBE, with one exception: in the event that a voter returns a ballot with a removed scratch-off surface, no shortcode receipt should be published. Providing such a receipt when had been revealed would violate the property of receipt freeness, since the two pieces of information combined would reveal the choices of the voter. Instead, the election authority should make a post to the bulletin board identifying that the ballot had its scratch-off removed. The voter’s choices should then be transcribed faithfully onto a new encrypted ballot by a multipartisan ballot duplication team, like those currently employed in absent voter counting boards across the country. This new ballot can be cast as normal, ensuring the voter’s selections still appear in the public tally. This ensures that the addition of the system’s novel properties cannot introduce new sources of disenfranchising voter error, thereby providing the property of harmlessness to our scheme.161616This also introduces the risk that an adversary might change the voter’s selections and remove the scratch-off surface to eliminate any direct evidence that the change occurred. A potential solution might be to introduce a grace period where voters who notice their ballot was duplicated in this process can instead spoil it and revote.

Initial Preparation (both schemes): Generate election paramters and vote data For each ballot: Roll random to seed ElGamal Encrypt each piece of vote data Gen. CCE commitments to the encryptions Gen. shortcodes/longcode based on commits RemoteVote Preparation: Pair ballots, avoiding shortcode collisions For each pair: Compute Publish ID, longcodes, commits, shortcodes Print ballot (two cols of shortcodes, ballot ID) Send ballots to voters RemoteVote Audit Process: After voters receive ballots, For each ballot, : If even, publish secret data for first column

If odd, publish secret data for second column

Observers can then: determine whether correct column was spoiled associate spoiled shortcodes with candidates Voter compares association with their ballot. If discrepancy, raise error; else, cast ballot normally SAFE Vote Preparation: For each ballot: Publish longcode, commits, shortcodes Print ballot column of shortcodes, longcode printed as ballot ID, random beneath scratch-off, Send ballots to voters SAFE Vote Audit Process: Voter optionally reveals scratch off, then: Uses and QR code to generate full ballot image Compares with printed shortcodes and ballot ID. If no discrepancy, encryptions were honest Requests replacement ballot, repeats choice Else, voter casts ballot as normal Ballot Return and Counting (both schemes): Authority receives and validates ballot, then publishes ballot ID and selected shortcodes Voter optionally compares with their choices Homomorphically tally voter’s choices by contest Anonymize aggregated commitments through mixnet Open commitments, decrypt, and process in clear Observers validate announced result

Figure 2: Procedures for initial setup, verification, and counting in our two schemes.

5 Extensions

5.1 Collection Accountability

One property missing from our schemes is collection accountability, which is an important element of dispute resolution. This property requires that voters be able to prove which set of ballot commitments they selected, so that a corrupt authority cannot misrepresent their choices on the public bulletin board.

We can extend our schemes to accomplish this by allowing voters who select a candidate to learn a portion of the corresponding encryption through some mechanism like Remotegrity’s scratch off surfaces [remotegrity]. Then, if the election authority posts the wrong shortcodes to the bulletin board, the voter can identify the commitments they actually selected and provide the secret encryptions with which those commitments are consistent, as evidence of their choice.

Because no observers are able to verify that the partial encryptions the voter presents are legitimate, this proof must be interactive. After the voter presents the information, the election authority then has the opportunity to open the commitment to the true underlying encryption—which should be inconsistent with the voter’s claim—and present a non-interactive zero knowledge proof that the opened encryption is a valid vote. If the authority is unable to do so, the challenge is assumed to be valid.

Note that the strength of this proof depends on the integrity of the hiding mechanism. If the encryption for a given candidate became known to an attacker improperly—say by using advanced imaging technology, compromising the printer, or simply by revealing all the information on a ballot and then counterfeiting a new one where the information was still hidden—they could use it to wrongfully implicate the authority for malfeasance. This increases the difficulty of making false allegations, but it may make them more persuasive when well executed.

There are a number of trade-offs associated with this modification. For one, we would lose everlasting receipt freeness, because a voter could make a false challenge claiming they selected a commitment they really did not. The election authority would then open this commitment to disprove the claim, revealing the encryption underneath. This allows the voter to produce a receipt that would reveal a candidate they did not select once cryptographic assumptions fail.171717If an attacker can impersonate a voter when making a challenge, they could use a similar strategy to compromise everlasting ballot secrecy by making false challenges that reveal other voters’ unchosen encryptions.

Additionally, if a voter made a selection and then changed their mind, they would have evidence they could use to falsely implicate an honest authority, but forbidding them from undoing a marking loses harmlessness. We can solve this by allowing the authority to post a disclaimer for such ballots, noting that a contrary proof might appear. A corrupt authority could abuse this to evade collection accountability, but it would place a bound on the number of cheated ballots, and—as with SAFE Vote—we can give a grace period for the voter to spoil and recast their ballot if it has a reported issue.

Note too that collection accountability guarantees only apply to active misrepresentation in the public tally. Ballots are still susceptible to being excluded from the tally by an attacker who intercepts and discards them, and there is no apparent mechanism to guard against this in a VbM context.

5.2 Assigning Voters Private Keys

Another possible addition would be to generate a key pair for each ballot. The public key would be posted to the public bulletin board alongside the rest of the ballot’s information, and the private key would be printed on the ballot to be disclosed directly to the voter. This would allow the voter to sign their challenge for the collection accountability extension, eliminating the threat to everlasting ballot secrecy. This would also allow for procedural controls that keep the authority from learning the mapping between voters and ballots while still allowing voters to exercise the revoting mechanisms discussed previously.181818Note that this breaks harmlessness; a voter who leaks their private key and makes a mistake that would allow revoting would compromise the integrity of their ballot.

5.3 System Synthesis

RemoteVote and SAFE Vote each have their own advantages and limitations, but by combining them we can get the best of both worlds, albeit in a less practical form. In this hybrid system, we print each ballot with two columns of shortcodes, one of which is spoiled through RemoteVote’s public audit process, and the other of which can be spoiled at will by removing a SAFE Vote style scratch-off surface.

RemoteVote SAFE Vote Synthesized STROBE Single-ballot STROBE Individual Cast-as-Intended Collective Cast-as-Intended Counted-as-Cast Eligibility Verification Ballot Secrecy Receipt Freeness Everlasting Ballot Secrecy Everlasting Receipt Freeness Coercion Resistance Ignorability Harmlessness Selection Consistency Software Independence Strong Software Independence Collection Accountability Dispute Resolution Advance Verification Discretionary Verification Independent Verification Unobservable Verification Vote-by-Mail Compatibility Complexity Tolerance provides property ○does not provide property ◐property is implementation dependent

Table 1: Comparison of properties achieved by our schemes and by STROBE.

This allows for the unification of a number of advantages. Voters can get discretionary verification and individual verification by choosing to remove the scratch-off and spoil their ballot as they do under SAFE Vote, but a corrupt authority still has no way of reliably identifying safe targets for cheated ballots; those who do not remove the scratch-off still may have verified the publicly spoiled column, giving unobservable auditing as well. We also gain advance auditing, because all challenges can be performed before results are published.

The disadvantage is that this system has higher complexity. Between the two columns of shortcodes, two encryptions hidden beside every candidate, two values concealed under scratch-offs at the bottom, a secret key used to sign challenges, and 512 bits of physically printed randomness per candidate (likely in the form of multiple large QR codes), the ballot would be challenging to use for those wishing to participate in the verification process. They would need to track and make sense of all the novel information presented to them. Perhaps future implementations can maintain these properties while simplifying the mechanism.

6 Comparisons and Conclusion

RemoteVote and SAFE Vote extend E2E-V strategies to better secure vote-by-mail, which is essential for the broader adoption of verifiable voting. They especially build upon STROBE [strobe], the first VbM-compatible E2E-V framework.

We compare the detailed properties of our schemes to STROBE in Table 1. As shown there, RemoteVote expands on the guarantees provided by single-ballot STROBE, while SAFE Vote trades the property of unobservable verification to gain individual cast-as-intended verification, along with discretionary and independent verification. The synthesized approach we introduced in Section 5.3, meanwhile, provides the strongest set of guarantees of any of these systems.

Other mechanisms for comparison exist as well; the formal properties are merely starting points. For example, STROBE fails to resolve disputes where the authority misrepresents the voter’s choices in the published shortcode receipts, while single-ballot STROBE additionally loses dispute resolution for allegations that a ballot’s shortcodes were printed beside the wrong candidates. RemoteVote and SAFE Vote are able to solve these problems with appropriate extensions, but are still vulnerable to an attack against processing procedure instead of ballot integrity; an adversary could unaccountably intercept and discard ballots, for example. All this nuance is lost when dispute resolution is regarded as binary.

Much remains to be done, including producing rigorous proofs of these schemes’ properties, creating and field-testing prototypes, and potentially further simplifying the voter experience. Nevertheless, we believe RemoteVote and SAFE Vote are important steps toward usable verifiability for vote-by-mail, which is a necessary precondition for the universal adoption of E2E-V in U.S. elections.


The authors thank Josh Benaloh and Olivier Pereira for insightful discussions and feedback. This material is based upon work supported by the Andrew Carnegie Fellowship, the U.S. National Science Foundation under grant number CNS-1518888, and a gift from Microsoft. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.