key: cord-0185892-sksysap7 authors: Crimmins, Braden L.; Rhea, Marshall; Halderman, J. Alex title: RemoteVote and SAFE Vote: Towards Usable End-to-End Verification for Vote-by-Mail date: 2021-11-16 journal: nan DOI: nan sha: c54627a2d55a0a0f5fc441648f3899152b5be868 doc_id: 185892 cord_uid: sksysap7 Postal voting is growing rapidly in the U.S., with 43% of voters casting 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. In the 2020 U.S. presidential election, 43% of voters cast their ballot by mail, twice as many as four years prior [24] . Although this increase was magnified by the COVID-19 pandemic, it follows on a long-term trend towards greater use of vote by mail [23] . 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 [19] . 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., [1, 10, 22, 25] ) 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 [5] , vote by mail (VbM) systems were largely absent from the verifiable voting literature. 1 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. Benaloh's STROBE Voting [5] 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 [3, 18] , a type of interactive proof that a voter can perform to check the honesty of the encrypting authority. Classically, this mechanism applies to in-person or Internet voting settings, where 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. 2 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. 3 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 its 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 practically usable in real VbM elections. We hope that the two schemes we propose represent progress in that direction. 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. A common goal of election system design is end-to-end verifiability. Systems with this property seek 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 [6] : 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 [7] .) Eligibility Verifiability means observers can verify that only eligible votes were included in the tally [7] , preventing threats like ballot-box stuffing and multiple voting. Many jurisdictions provide this property to some degree through the post-election publication of a 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. 4 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 [16] . 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 [16] . Typically, cast-as-intended is individually verifiable in E2E-V designs. Mechanisms for universal cast-as-intended exist [13] , but those are beyond the scope of this paper. Collective Verifiability means that voters can collaborate with each other to verify the system's integrity. Consider a design in which a voter can gain a certain level of confidence (e.g., 50%) that their ballot encryption is honest, but cannot individually increase their confidence beyond that level. Through collaboration with other mutually-trusting voters, each with their own independent partial confidences, these voters can jointly confirm the honesty of the system to asymptotically high degrees of collective confidence. 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 result [7] . Receipt Freeness further means a voter cannot prove their choices to a third party after voting and casting their ballot privately 5 , 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 [7] . 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 [20] . 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 [7] . 5 That the voter must cast their ballot privately is implicit in most articulations of receipt freeness, which entertain only supervised voting at the polling place. Failing to articulate it in a VbM context, however, blurs the line with other stronger properties such as coercion resistance. If a voter is compelled to surrender their voted ballot and signed envelope to a coercer, this would "prove their choices to a third party," but substantively this attack is better identified as a failure of coercion resistance. The importance of usability is well recognized in voting system design, and past failures on this front have had enormous consequences. 6 Nevertheless, voting system usability has not been formalized in the same way as other E2E-V properties. Here we attempt to define aspects of usability that can be used to discuss and compare systems (albeit with some room for subjective interpretation): Ignorability 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. Harmlessness 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. 7 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 [21] . 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 [21] , 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 [2] . An important subproperty is collection accountability, which means a voter can prove it if the authority misrepresents their choice in the public tally [7] . Verification processes involve a series of checks that have properties and side effects of their own. We explicitly define these properties here, since they can 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 during the election. 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 they monitor this over several elections, they can target later ballot manipulation toward voters who are least likely to detect the fraud. Note that the adversary can learn the identities of some of those who engage in the verification process, but not the identities of everyone who does, since that would reveal exactly who does not verify. E2E-V schemes vary in what modes of voting and what counting methods they support. We consider two aspects of such compatibility: Vote-by-Mail Compatibility means that a system can provide its intended 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. Our schemes use a similar approach to STROBE [5] . 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 to 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. 8 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 observers can use the published shortcode receipt 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., [4, 9] ) 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. Also, there is 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 methods and cannot always directly represent a voter's selections in the published shortcode receipts. Second, when we generate our encryptions, we use a random value R to seed a PRNG, and use the output to seed ElGamal for every encryption on a given ballot. This way, revealing R to a voter allows them to reconstruct all the encryptions on their ballot, a property used in SAFE Vote's challenge process. 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 [12] and further elaborated on in [20] . 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 [20] , which means the privacy properties remain even if all modern cryptographic assumptions fail. We generate these commitments immediately after generating our encryptions and use themrather than the encryptions themselves-to derive shortcodes and ballot IDs. After the mixnet step in our tallying, we open the commitments to the underlying encryptions before decrypting. The process is otherwise as previously described. 9 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. 10 This is not strictly a difference from STROBE, as this early commitment is still possible in the original design. It is essential for RemoteVote's challenge process, however, and so is important to specify here. RemoteVote ballots (Figure 1a ) look identical to those of single-ballot STROBE, but the challenge process is markedly different. While STROBE attempts to 9 Using CCEs to implement both a homomorphic and mixnet tallying step is usually infeasible for large-scale elections [12] . However, because the format of possible votes is highly predictable, an exhaustive search of plaintexts is easy, and decryption becomes cheap enough that we can use the PPATS system for both. 10 Alternately, we can simply post the commitments (which can be used to derive the rest of the information), but posting everything makes the process easier for observers. facilitate an interactive challenge through limited communication channels, Re-moteVote 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 their ballots, giving a greater degree of dispute resolution. There is also no way for the authority to be confident that 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 it wanted. 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. 11 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 form. After the ballots are delivered to voters, randomness is generated in a publicly accountable manner (e.g., [17] ) and used to deterministically select one column to spoil for each ballot. 12 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 the voter trusts the public randomness, they know that a forged encryption on their ballot would have had a 50% chance of being revealed. 13 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. 11 Pairs should be constructed such that there is no shortcode collision within a contest. 12 One effective heuristic would be hashing the randomness with the ballot ID and selecting a column based on the resulting hash's parity. 13 Even if the voter does not trust the entire public randomness, they can still have confidence in this system. Only one in 2 2 n possible pairings would be fully resistant to detection, where n is the number of trustworthy bits. Validating that a particular pairing belongs to that set would require computing 2 n 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. 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. This maintains discretionary auditing, but also incorporates independent auditing and ensures that 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 (Figure 1b) contain four special features: 1. Each option has a single corresponding shortcode printed beside it. 2. The longcode is printed as the ballot ID. 3. The value of R is printed on the ballot and concealed by a scratch-off surface. 4. The ballot includes a large QR code, which, when decrypted using R as the key, provides the true randomness used to generate the ballot's commitments. 14 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 R. Trusted third-party software can use this R 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 are satisfied with the encryptions and cast a ballot. 15 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 R 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, so that 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. 16 Initial Preparation (both schemes): 1. Generate election paramters and vote data 2. For each ballot: (a) Roll random R to seed ElGamal (b) Encrypt each piece of vote data (c) Gen. CCE com'ts to the encryptions (d) Gen. shortcodes/longcode from com'ts So far, our schemes lack collection accountability, which is vital for dispute resolution. It requires that voters be able to prove which commitments they selected, so a corrupt authority cannot misrepresent their choices on the 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 [25] . 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 information about the secret encryptions underlying those commitments 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 authority can 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 presumably 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. 17 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 could still be susceptible to being excluded from the tally by an attacker who intercepts and discards them, and there is no apparent cryptographic mechanism to guard against this in a VbM context. Another possible extension would be to generate a key pair for each ballot. The public key would be posted to the 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. 18 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. 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 17 If 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. 18 Note 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. authority still has no way of reliably identifying safe targets for cheating; voters 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 R 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. Our schemes show that E2E-V can be used to secure VbM with practical usability. They build heavily on STROBE [5] , 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 they are still vulnerable to an attack against the processing procedure instead of ballot integrity; e.g., an adversary could unaccountably intercept and discard ballots. 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. Helios: Web-based open-audit voting Dispute resolution in voting Ballot casting assurance via voter-initiated poll station auditing Simple verifiable elections STROBE-Voting: Send Two, Receive One Ballot Encoding End-to-end verifiability Public evidence from secret ballots Second Georgia county finds previously uncounted votes Running mixnet-based elections with Helios Civitas: Toward a secure voting system Millions of Americans are receiving absentee ballot applications from outside groups Election verifiability or ballot privacy: Do we need to choose? Universal cast-as-intended verifiability Four vote-by-mail ballot applications do not mean four votes How the 2000 election came down to a Supreme Court decision Towards a framework on the security requirements for electronic voting protocols A gentle introduction to risk-limiting audits What did I really vote for? On the usability of verifiable e-voting schemes National Conference of State Legislatures: Voting outside the polling place: Absentee, all-mail and other voting at home options Verifiable elections with commitment consistent encryption: A primer Software Independence Revisited. In: Real-World Electronic Voting: Design, Analysis and Deployment Selene: Voting with transparent verifiability and coercion-mitigation How We Voted in 2020: A first look at the Survey of the performance of American elections Voting and registration in the election of Remotegrity: Design and use of an end-to-end verifiable remote voting system We thank Josh Benaloh and Olivier Pereira for insightful discussions and feedback. This work was supported by the Andrew Carnegie Fellowship, the U.S. National Science Foundation under grant no. CNS-1518888, and a gift from Microsoft.