The XIMIX Project

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
The verification process for an RPC style mix requires 5 things to be checked. An extra step is required in the case of Ximix to accomodate the mapping of EC points to actual candidate numbers that are represented in the CSV files representing the ballot. This extra step may appear to be more complicated than it needs to be as Ximix is designed to accomodate packed ballots, which allow several preferences to be represented by one EC point, as well as a simple bijection from points to candidate numbers.

The verification tool currently performs the following checks:

  - verifies that the transcript and proof files were produced by a valid MixNet.
  - verifies the initial ballot files and the audit log of the initial state of the board matches.
  - verifies that the commitments opened matches what would be predicted by the random seed calculated at the end of the shuffle.
  - verifies that the opened commitments are valid and match the known witness values.
  - verifies that the proofs of decryption (ie. the proof that the result of decryption for a specific node could only have been calculated using the private key corresponding to the published public key for the specific node).
  - verifies that the CSV represents a correct representation of the final decrypted result, taking into account packed ballots where required.

The source for an example controlling main for the verifier can be found in org.cryptoworkshop.ximix.tool.Verifier. For the curious, it may help to know that the extra 6th step is encapsulated in a nested private class CSVVerifier contained in the Verifier class.

The verifier requires 9 arguments:

  - the trust anchor for the signatures provided
  - the public key used to encrypt the ballots
  - a boolean (true if pairing has been used on shuffling on same nodes, false otherwise).
  - the location of the directory of the initial encrypted ballots
  - the file representing the properties for the ballot (this provides data on how to unpack packed ballots)
  - the location of the transcript files created over the course of the shuffle and decryption.
  - the region of interest 
  - the type of ballot in the region of interest
  - a meta-data associated with the type.

Region, type, and meta-data are assumed to correspond to the format used in vVote. For example:

8159599f-5150-4e0c-a694-9c2a5e4abba6_ATL_E.blt

Indicates region number 8159599f-5150-4e0c-a694-9c2a5e4abba6, type ATL and meta-data E.

We would welcome further input, clean room attempts, or comments, on the subject of verification.