Audit Specification

From Scantegrity Wiki

This document explains how to independently verify the correctness of a Scantegrity election using the publicly available output from the Scantegrity Election Manager (SEM).

Overview and Relation to Other Audits

This audit will be presented in chronological order. It includes some initial validation of the SEM output as various tasks are completed, however is mainly a post-election audit of the tally.

The post-election audit assumes the confirmation codes that are asserted to appear on print audited and voted ballots are correct. The correctness of this assumption can be established independently by the print audit and receipt check. For a higher-level view of the system, please see the Software Design Document.

Briefly, in an election between Alice and Bob, a voter who selects Bob will receive a confirmation code; say, STZ. The association between the candidate Bob and the confirmation code STZ is committed to prior to the election. The print audit probabilistically establishes that the committed associations between candidates and codes is consistent with what is printed on each ballot. The receipt check probabilistically establishes that, in this case, a vote should be recorded for the candidate associated with code STZ in the committed data. Finally, the post-election audit described here probabilistically establishes that the code STZ is added to the candidate associated with it in the committed data, without revealing the candidate is Bob.

Data Files

The necessary data files are hosted on a server and each election is given an name. We refer to this as the election directory or $ElectionDir. For example, the Takoma Park Mock Election is hosted at:

The files can be downloaded from a website interface found at $ElectionDir/getfiles or directly. Files appear at different times throughout the election. At the conclusion of the election, all the files can be extracted from,

  • $ElectionDir/

Individual file descriptions follow. They are grouped into chronological events. Clicking the name of the file will provide a sample of the file, a schema for the file, and the steps necessary to audit the contents of the file.

Election Definition

The following files define the nature of the election. No private data is needed for their creation.

This file defines the number of questions (contests) on a ballot, how many answers (candidates) for each question, the scoring protocol, and the number of marks that invalidate the ballot. Scoring protocols include rank and one_answer (plurality).
This file contains a sample layout of the ballot. It is not needed for the audit, however may be useful as a reference for interpretation of the ElectionSpec.xml data.
  • $ElectionDir/geometry.xml
This file defines the regions on the ballot where items of interest are for the optical scanner. It is not needed for the audit.
By default, the SEM displays the results of each contest for an anonymized ballot together. This can allow voters to encode a unique pattern across any number of contests to tag their ballot, which can be used for vote selling or other undesirable coercion attacks. As a deterrent, questions, or groups of questions, can be put into partitions that are presented independent of each other in the final output. This file defines which question is assigned to which partition.

Meeting 1 (Election Setup)

Specifies the number of ballots, the number of backend instances, and an election constant for use by the commitment scheme.
Outputs cryptographic commitments to the structure of the backend but not the actual codes appearing on the backend.

Meeting 2 (Electronic Ballot Creation and Audit)

Selects a random half of ballots (i.e., table entries) so that the structure of the backend can be verified. This meeting is not necessary but is designed to attempt to identify problems before the actual election begins (after which, problems with the structure would be impossible to recover from without running a new election).
For the selected entries, they are traced through the backend. These are not used in the election.
The residue entries, which will make up the ballots used in the election, have confirmation codes, serial numbers, and passwords generated and committed to.
The software generates the confirmation codes with an arbitrary dictionary of symbols. The test election uses a subset of the valid alphanumeric characters, so that characters that are easily confused are removed from the set.

Meeting 3 (Results Posting)

On voting day, the scanner records the positions marked. These are put through the initial permutations and posted here as input to the tally.
The marks are placed into the Punchboard and the public contents of the Punchboard are output; including the asserted final tally.
For each mark in MeetingThreeIn, the commitment to its corresponding code is opened for use in the receipt check.
For each ballot that was spoiled, all the commitments to codes on the ballot are opened and posted.

Meeting 4 (Final Audit)

To check that the asserted tally was correct, a cut-and-choose protocol is used. This file contains the random challenges.
In response to the challenges, certain information is released about the construction of the Punchboard that provide probabilistic evidence that the tally was computed correctly.
To be completed.
In the event of a dispute over a receipt deemed to be plausible evidence of error or malfeasance, the codes on a ballot may be completely revealed to determine if the confirmation code asserted by the voter to be correct is a potential code for that contest on that ballot.

Sample Data

This specification contains data from a sample election. The entire set of files may be downloaded here and this set, as a sample, includes the private data which is never publicly posted.

In addition, a number of elections have been run using Scantegrity and Punchscan. While not all of them follow this specification exactly, they may be useful as a reference point: