Version 2.1 of the ElectionGuard Design Specification has been significantly extended compared to version 2.0.0 and contains several significant changes.
- Key generation: Three sets of keys are now generated by the guardians in order to support distinct uses; and a guardian record has been created, which the guardians must verify at the end of the key generation process.
- Ballot preparation: a selection encryption identifier is now created for each ballot, which is used to link together all the ciphertexts and proofs associated to a single ballot; signed ElGamal is now used for encrypting all data other than voter selections; the ballot nonce must now be encrypted and included in each ballot.
- Confirmation codes: A voting device information hash has been added; the simple ballot chaining mode has been detailed and refined.
- Tallying operations: Guardians now verify the election record before starting the tallying operations; support for weighting ballots during aggregation has been added; the verifiable decryption process and protocols have been detailed and updated.
- Audit of challenged ballots: The opening of challenged ballots has been made more efficient by releasing relevant encryption nonces instead of performing verifiable decryption.
- Hash computation steps have been revised and updated in many places, and a hash function that maps to integers modulo q has been defined separately.
- Several components have been designated as optional such as supplemental verifiable fields, contest data, and pre-encrypted ballots.
- A concrete list of verification steps for pre-encrypted ballots has been added.
ElectionGuard Serialization Specification
This specification exists to help anyone trying to write a compatible implementation or, crucially, anyone trying to write a verifier. The design says what has to be done, how, and why. The data serialization spec describes the data formats used in the implementation to achieve the design. The data serialization spec currently matches the v2.0 implementation.