Rescans and Recounts
Warning
This is a documented but not currently implemented capability. See the Roadmap for implementation details and status.
Overview
In the course of an election with paper ballots, occasions may arise when all or some of the ballots in an election may need to be rescanned without being in the presence of the voter.
For example, if a precinct scanner fails on election day, some municipalities may require a new scanner to be activated and the ballots scanned through the failed scanner to be re-scanned in the new scanner; those rescans would likely not be conducted in the presence of the affected voters, and the verification codes generated from the subsequent scans would not be available to them.
Similarly, some elections require multiple recounts, including hand tallies, to resolve challenges or recounts triggered by narrow margins of victory. Ballots may be included or excluded from subsequent recounts dependent on the interpretation of the scans or their inclusion or exclusion in the the subsequent tallies.
Info
Depending on how the ballot is encrypted (such as whether ballot-chaining is being used), the verification codes generated in the rescan would not be the same. The "default" implementation of ElectionGuard, which uses the unique ID of the device performing the encryption as part of the encryption itself, would generate a different verification code if the same ballot is scanned on a different device. If ballot-chaining or any time-based component were included in the encryption, even subsequent scans of the same ballot on the same scanner would generate a different verification code.
When a voter checks whether their ballot was included in the ElectionGuard published artifacts, the information should reflect whether the ballot was included (and even more importantly not included) in any subsequent tallies published by the election administration. This must be accomplished without undermining the core integrity and privacy concerns of the verification processes.
Warning
The proposed process mandates a unique ballot identifier be generated by the host voting system (not ElectionGuard), printed on the ballot, and captured as part of the ElectionGuard metadata.
Proposed Approach
To maintain the security and integrity of the original election record, rescans and recounts are guardian-based processes. This requirement presents potentially significant additional compute both for the local guardian device / hardware security module and any cloud-based approach to scale the cross-tally mapping.
Encrypting a Unique Ballot ID
Since a rescan or recount can occur on any independent device, the information for mapping must be present on and derived from the paper ballot itself. Specifically, in addition to all the contests and candidates, there must be an ID unique to the election printed on the ballot. When scanned by the scanner, that ID is included in the encrypted ballot metadata encrypted by the auxiliary guardian RSA key separate from the El Gamal encryption1 used for the ballot contents.
Alert
Municipalities that do not allow the printing of unique identifiers on their paper ballots cannot use ElectionGuard for the rescan scenario, since there is no way to perform any mapping across independent tallies
Diffing an Election
Invoking a Rescan or Recount
After the base ElectionGuard verifiable tally has been generated (and, optionally, published) a rescan or recount can be performed.
Optimizing the Compute
-
Because the primary joint public key is an ElGamal key, it is optimized for the ones and zeroes that constitute the contents of a ballot, not the generic string values necessary to support arbitrary IDs. ↩