TLDR: E-voting system uses pedersen commitments, but doesn't provide any evidence that the generators used are nothing-up-my-sleeve values. To understand what

TLDR: E-voting system uses pedersen commitments, but doesn't provide any evidence that the generators used are nothing-up-my-sleeve values. To understand what a pedersen commitment is think "cryptographic hash" but constructed so that you can 'add' hashes to get the hash of the added values. Pedersen commitments require as system parameters multiple base points where, for soundness, no one knows the discrete log any of them with respect to each other. The normal way to accomplish this is to generate them all in a "nothing up my sleeve" way by hashing some data. In my work on confidential transactions ( https://people.xiph.org/~greg/confidential_values.txt https://people.xiph.org/~greg/confidential_values.txt ) the base points I used were the standard secp256k1 generator, and a second point constructed by hashing the standard generator with sha256. If implementations of the SwissVote system were initialized in the say way they could simply add the information about the hashed data to their audit logs, even after the fact. If, instead, they picked the base points "randomly" then they could not prove that past usage wasn't compromised. I have often been frustrated by the lack of clarity in academic cryptographic papers about the exact trust implications about initialization -- e.g. it often takes a careful reading to tell if a paper requires a trusted setup, if the values can just be chosen in a provably random way (and if so, will a simple method suffice or is there a strong requirement on uniformity) ... but pedersen commitments (even the vector versions) are really bread and butter simple stuff. I would be worried that anyone who didn't know that choice of the base points resulted in a trapdoor would be unlikely to spot actually subtle implementation or algorithmic mistakes.