Workshop on Auditing and Verification for Election Security (WAVES)

What are the key challenges in explaining RLAs to practitioners, and what strategies can we use to address those challenges. What are the worst-explained aspects of RLAs and what can we do to explain those aspects better? Is it possible to develop guidelines for the development of RLA software to ensure that it is accessible and more explainable to practitioners? Should papers on RLAs be accompanied by a supplementary “For Practitioners” document?

Randomness is fundamental to many electoral procedures intended to promote fairness. For instance, the position of candidates on a ballot can influence voter behaviour; therefore, the method for ordering candidates must itself be demonstrably fair. A common mechanism is a random ballot draw, intended to yield a uniformly random permutation of candidates.

To be credible, the randomness used in such procedures should satisfy three properties:

1. bias-resistance, i.e., no party can influence or skew the outcome;
2. unpredictability, i.e., no party can learn the outcome before a defined commitment or cut-off point; and
3. verifiability, i.e., observers can verify that the output was produced by the prescribed method.

Despite broad recognition of these principles, real-world implementations often fall short due to subtle yet important pitfalls in randomness generation and its audit trail. Consider the random ballot draw used by the Victorian Electoral Commission (VEC). According to public information, the VEC employs software running on a single machine, which calls the operating system’s cryptographic RNG API. While this can, in principle, produce high-quality randomness, a core trust gap remains: the single operator of the host can select on the outcome (e.g., repeatedly re-run the draw until a favourable result appears) or pre-sample the outcome in advance, and then publish only the chosen run. Even with strong correctness mechanisms such as zk-SNARKs or trusted hardware, these behaviours may remain undetectable, because such mechanisms attest to the correctness of a particular run but do not prevent cherry-picking, replay, or off-line trials. Moreover, existing auditing practices appear focused on the statistical quality of the RNG itself rather than the end-to-end integrity of the drawing process (e.g., uniqueness of the draw, time-binding, and public commitments).

This proposal seeks to develop a problem-solving session that surfaces these issues and develops practical candidates for fair and verifiable electoral randomness generation. The session will analyse real configurations, articulate the threat model, and discuss practical, transparency-oriented designs that strengthen public trust in election procedures.

Implementations of e-voting systems are not static objects, they (seem to) need to be regularly updated. However, these updates may introduce new errors which invalidate prior security analysis. The strengths and limitations of different design architectures to mitigate these problems do not appear to have been studied in the context of e-voting.

As an example, a recent iteration of the Swiss Post voting system which included at the design level only minor changes resulted in over 100,000 lines of changes to the code base.

In the past decade, several open-source voting systems have been made public, by vendors or by academics. In general these software projects include a library for cryptographic building blocks. It would make sense to factor out this development effort and have a common SDK that would provide the required building blocks to build an e-voting system. Apart from saving development efforts, the goal would be to increase the confidence by concentrating the scrutiny effort of the community in a single place. ElectionGuard is a project that goes exactly in this direction. However it did not get all the momentum it deserves, perhaps due to the fact that the SDK is targeting only part of the needs, namely Helios-like systems for in-person voting. The idea of having a broader range SDK that would covers various forms of e-voting, including Internet voting, has been discussed in a recent Dagstuhl seminar (Oct 2025).

In the proposed session, the goal would be to concentrate on the API level, where different opinions are very necessary. Critical choices must be made: does the API expose many low-level functionalities or does it concentrate on medium-level ones? How many variants of e-voting systems are supported? Do the functions of the API have their input/output data in an internal language-specific format, or is everything serialized in byte-strings? Not everything can be decided in a short session. The idea would be to do the exercise for two parts of the API and see the implications: mixnets and zero-knowledge proofs.

For verifiable mixnets, here are some questions to be answered:

• which algorithm? (Terelius-Wikström, Bayer-Groth, other?)
• which level of optimization? (separating off-line and on-line parts? multi-thread / multi-node parallelism?)
• how to provide an API that can do variants? (multi-recipient ciphertexts, mix several lists with the same permutation, mix commitments?)

For zero-knowledge proofs, we would concentrate on the family of Sigma protocols that arise when working with discrete-log based systems. The questions for the API include:

• how to find the good balance between flexibility and a fixed and secure framework?
• what is a complete list of the ZKPs that are useful in various e-voting systems?
• does it make sense to provide a toolkit allowing system designers to build their own ZKP, for instance a framework for homomorphism-based statements (à la Maurer 2009), together with OR-proof combiners?
• how to limit the risk with the “context” being not complete enough in the string that is hashed during the Fiat-Shamir transform?