Æternum: A Decentralized Voting System
with Unconditional Privacy
Christian Killer, Markus Knecht, Claude M¨
uller, Bruno Rodrigues,
Eder Scheid, Muriel Franco, Burkhard Stiller
Communication Systems Group CSG, Department of Informatics IfI, University of Zurich UZH
uhlestrasse 14, CH—8050 Z¨
[killer|rodrigues|scheid|franco|stiller]@iﬁ.uzh.ch, firstname.lastname@example.org, email@example.com
Abstract—Remote Electronic Voting (REV) systems allow vot-
ers to cast their votes in an uncontrolled, distributed environ-
ment. At the same time, the REV system must provide ballot
privacy and veriﬁability of the ﬁnal tally. Research has proposed
REV schemes offering ballot privacy based on computational
intractability assumptions, but only a few provide Unconditional
Therefore, this work proposes Æternum, a REV system with a
voting scheme providing UP. Æternum does not require trust in a
central authority, nor does it assume computational intractability
of an underlying mathematical problem to provide UP. To satisfy
UP’s minimal trust assumptions, Æternum uses a permissioned
Distributed Ledger (DL), that forms a decentralized network of
permissioned nodes, which serve as a transparent, tamper-proof
Decentralized Public Bulletin Board (DPBB).
Remote Electronic Voting (REV) is an essential topic, con-
sidering the further digitalization of society, which demands
an increasingly efﬁcient, transparent, and veriﬁable voting
processes. REV allows for casting votes over the internet,
applying cryptographic protocols to achieve End-to-End (E2E)
veriﬁable schemes . Furthermore, immutable Public Bul-
letin Boards (PBB) offer a transparent audit trail of the voting
process. REV requires less physical labor at different stages of
the voting process and infrastructure , if designed securely
and correctly, it allows for tallying results faster, in contrast
to traditional, paper-based voting systems. REV reduces the
threat events of traditional remote voting systems (e.g., poten-
tial threat events emerging during tallying, or the manipulation
of votes sent by postal mail ). However, the complexity
and technical operations of a distributed high-security system
introduce new challenges, e.g., trade-offs between veriﬁability,
transparency of the process, and voters’ privacy.
Ballot Privacy (BP) is one of the core requirements in any
electoral process. In the context of REV, BP is divided into
basic, everlasting, and unconditional BP. Basic BP relies on
the assumptions of (a) computational intractability and (b) a
trusted central authority . Since future adversaries may
access Quantum Computers (QC), it would be possible to com-
promise the conﬁdentiality and integrity of such cryptographic
primitives by breaking the underlying hardness assumptions,
e.g., Integer factorization, and the discrete logarithm . It
is crucial to protect BP against present and future adversaries,
thus, not relying on computational intractability.
However, REV schemes often apply cryptographic protocols
based on Mixnets or Homomorphic Encryption, which rely on
hardness assumptions to achieve BP . Thus, Unconditional
BP (UP) does not assume computational intractability and
eliminates the need for Trusted Third Parties (TTP) . Min-
imizing trust assumptions and removing the reliance on TTPs
for speciﬁc tasks within the voting process is a fundamental
argument for decentralized voting systems, e.g., for voting in
a consortium of industry participants. Instead of relying on
TTPs, the UP-based REV system can be fully decentralized.
Since most prior work on REV does not achieve UP, they rely
on a TTP or base their privacy on a secret shared between
multiple trusted entities .
Æternum’s voting scheme provides UP and does not rely
on a single trusted authority . In order to achieve UP, the
deployment of a decentralized PBB is required. Distributed
Ledgers (DL) offer a suitable approach to deploy a Decen-
tralized PBB (DPBB) to achieve such a distribution of trust
among authorities . DLs are tamper-proof and immutable,
replicate data securely, making them ideal for storing ballots
that should not be manipulated by anyone .
This paper proposes Æternum, the ﬁrst DL-based REV
system combining a voting scheme with UP and a public
permissioned DL, which serves as a DPBB. Æternum’s voting
scheme is based on Non-Interactive Zero-Knowledge Proofs
(NIZKP) . UP holds under the assumption of the existence
of a PBB and an anonymous channel . Furthermore, the
trust assumptions do not impact UP, but are fundamental
for veriﬁability and correctness i.e., trusted authorities are
required for fairness. For instance, homomorphic threshold
encryption is used to disallow trend analysis during an open
voting period. Computational intractability assumptions are
only relevant during the voting period to prevent the creation
of invalid votes .
The remainder of the paper is organized as follows. While
essential deﬁnitions are presented in Section II, Section III
discusses Æternum’s system design followed by the imple-
mentation details in Section IV. Section V renders the discus-
sion, Section VI outlines the security analysis and VII the
evaluation. Finally, Section IX draws conclusions and outlines
II. DE FIN IT IONS
Prior work deﬁned and reﬁned desirable privacy and veri-
ﬁability properties for REV systems. Veriﬁability notions for
voting schemes are deﬁned as Individual , Universal 
and End-to-End , plus the Eligibility Veriﬁability . Bal-
lot Privacy (BP)  can be deﬁned with different assumptions
being further categorized into basic BP, everlasting BP ,
perfect BP , and Unconditional Privacy (UP) .
Deﬁnition 1 (Everlasting BP (EP)).A voting system with EP
does not allow even a computationally unbounded coalition
of voters or outside observers to determine for whom a voter
EP removes the assumption of computational intractabil-
ity , but still requires trust in Voting Authorities (VA). The
VA is an entity responsible for the setup and execution of an
election or poll. Perfect BP is deﬁned as a voting system that
does not allow a computationally bounded entity to determine
for whom a voter voted .
Deﬁnition 2 (Unconditional BP (UP)).A voting system with
UP does not allow anyone, neither voters, outside observers,
nor VAs, be they computationally unbounded or not, to deter-
mine for whom another voter voted .
Under the assumption of a perfect BP, even if VAs conspire,
they are unable to link votes to voters. Therefore, a voting
scheme with perfect BP does not require trust in the VAs
or other parties. However, this privacy property relies on
computational intractability and, therefore, is not everlasting.
In this case, by combining everlasting BP and perfect BP, it
is possible to achieve Unconditional PB.
III. ÆTE RN UM SY ST EM DESIGN
The description of (i) key assumptions of the voting scheme
and (ii) of the voting scheme of Æternum itself lay the basis
for achieving UP.
A REV system is complex and the approach developed
enables UP. Thus, the system’s architecture impacts design
decisions  as assumed and formulated within Table I.
TABLE I: Assumptions of Æternum
A1Every eligible voter is uniquely identiﬁable.
A2The connection between the voter client and the DPBB is per-
formed over an anonymous channel.
A3Every voter is only allowed to cast a single vote once.
A4Initial trust in the VA to set up independent generators.
A1assumes the existence of an Identity Management (IdM)
system, which allows VAs to authenticate users and generate
a list of eligible voters (Ueligible). Depending on the use case,
the IdM is performed by a TTP that is either a governmental
authority for votes and elections or, in a corporate setting, an
external IdM provider. A2assumes anonymous communica-
tion channels. A3is given, i.e., by the current Swiss regulation,
which does not allow for multiple votes . A4refers to
cryptographic generators that need to be set up by the VA.
Fig. 1: The Four Protocols of the UP Scheme , 
B. Voting Scheme
Æternum utilizes the voting scheme from  (cf. Fig. 1),
which does not impose any speciﬁc encoding for ballots, since
they are not encrypted. It contains four protocols and the main
stakeholders are VAs, voters, and the DPBB. The following
notations are used to specify the major basic constructs, while
the full protocol’s details are available in the source code 
and  due to space restrictions.
1) Registration Protocol (Voter): First, (1) a voter Vpicks
the private credentials α, β at random from Zqand is able to
(2) compute a public credential u=hα
2.Zqis the set of
integers modulo q. In the third step, (3) the public credentials
uare posted to the DPBB, registering Vfor the vote .
Registration Protocol (Voter V)
1:Pick Private Credentials α, β ←$Zq
2:Generate public credential u=hα
3:Post v, u to PBB
2) Preparation protocol (Voting Authority): First, (1) VA
veriﬁes the eligibility of the registered voters and compiles
a list (Ueligible ), which links eligible voters to their public
credential ui, where Nis the electorate size. As mentioned
in assumption A1, a suitable IdM is required, which allows
the VA to verify a voter’s eligibility. Second, (2) from the set
of public credentials, a polynomial P(X) = QN
calculated. P(X)is required for the proofs generated later in
the protocol. The polynomial’s coefﬁcients A= (a0, . . . , aN)
are posted to the DPBB along with the list of voters U. Anyone
can verify the correctness of the polynomial by recalculating
it from U. Third, (3) the VA chooses an election generator
h∈Gqand (4) ﬁnally posts it to the PBB.
Preparation Protocol (Voting Authority VA)
1:Deﬁne Ueligible = ((V1, u1),...,(VN, uN))
2:Calculate polynomial P(X) = ΠN
3:Select generator ˆ
4:Post (U, A, ˆ
3) Vote Casting protocol: Before starting the vote casting
stage, the voter checks whether he/she is included in the list
of eligible voters. If yes, the voter (1) selects a vote vand (2)
generates an election credential ˆu=ˆ
hβ. This is crucial since
the voter does not authenticate with the public credential u,
but instead, the voter sends ˆuwith the ballot. This step actively
removes the link between the voter’s identity ufrom the vote
and requires the voter to generate three Non-Interactive Zero-
Knowledge Proofs (NIZKP) .
Then, two Pedersen commitments  are computed: (4)
a commitment c=comp(r, u)to the public credential u
is created, using random r∈RZp, and also, commitment
d=comq(s, α, β)to the private credentials is computed, with
In (5), three NIZKPs are computed. First, a set membership
proof π1is generated, proving that cis a commitment to one
of the credentials in the list of voters. Second, commitments
dand care used to create the second NIZKP π2, proving
knowledge of the private credentials αand βthat were used
to generate u. Finally, the voter needs to prove that the same β
was used to generate the election credential ˆu, which was used
in the generation of the public credential u. In this regard, π3
uses a proof of equality of discrete logarithm, thus preventing
the voter from sending multiple ballots with different ˆu.
Finally, (6) the ballot tuple B= (v, ˆu, c, d, π1, π2, π3)is
posted to the DPBB using an anonymous channel that does
not allow linking its ballot to it. The vote itself can be added
in plaintext to the ballot in any format. However, remember
that voters need to compute NIZKPs dependent on v. When
computing the challenge for these NIZKPs, the vote is part of
the input into the hash function and impacts the computational
effort. Using the vote as input ties vto Bbecause it is used
as input again when verifying proofs. If a different v0is sent
within B, the proof veriﬁcation will fail.
Vote Casting Protocol (Voter V)
1:Select vote v
2:Compute election credential ˆu=ˆ
3:Pick r∈RZpand s∈RZq
d=comq(s, α, β)
π1=NIZKP[(u, r) : c=comp(r, u)∧P(u) = 0]
π2=NIZKP[(u, r, s, α, β) : c=comp(r, u)
∧d=comq(s, α, β)∧u=hα
π3=NIZKP[(s, α, β) : d=comq(s, α, β )∧ˆu=ˆ
6:Post ballot B= (c, d, v, ˆu, π1, π2, π3)to PBB
4) Tallying protocol: After the vote casting is concluded,
the tallying protocol is executed. Since all data on the PBB are
public, anyone can fetch all ballots B(1), and then verify the
proof of each ballot (2). If duplicate votes are allowed, they
need to be cleaned at this point (3), e.g., by simply dropping
all but the last ballot corresponding to the same ˆu, and (4),
the ﬁnal tally can be accumulated from the plain text votes.
1:Retrieve set Bof all ballots from PBB
2:For each B∈ B,verify π1, π2, π3
3:Detect duplicates based on ˆuand resolve
4:Compute ﬁnal election result
Æternum is implemented as the up-voting-system Go
module available on GitHub  for which packages and their
dependency hierarchy are shown in Fig. 2.
Fig. 2: Source code package structure
Each of the three cli packages contain a Command Line
Interface (CLI) application. The cli/pbbd package contains
the entry point for the PBB application, i.e., compiling it
generates an executable that can be deployed on a PBB
node. The other two packages cli/vcli and cli/acli
compile to a voter and a voting administration CLI application
respectively. All three cli packages rely on the pbb package
that implements the PBB and functionality for CLI interaction.
Finally, the crypto package implements the cryptographic
primitives required by the Æternum voting scheme, as de-
scribed in Section III-B. The pbb package implements a
Cosmos-SDK module (following a similar approach as e.g.,
the staking module ).
The details of the Æternum architecture are depicted in
Fig. 3. The DPBB is composed of a DL network consisting of
(i) consensus nodes and (ii) full nodes. Full nodes store a copy
of the complete DL and expose web endpoints for clients to
post and query. Consensus nodes additionally participate in the
consensus mechanism by creating new blocks and validating
transactions. In the case of an election or voting, consensus
nodes should be operated by trusted authorities, which may
not necessarily trust each other, while anyone can operate a
full node and directly observe the voting process.
Although the prototype implementation uses Tendermint’s
consensus mechanism (requiring at least 2/3of all consensus
nodes to behave honestly), a suitable alternative is Proof-of-
Authority , . For instance, in Switzerland, cantons,
down to municipalities can participate in the consensus, only
requiring at least 1/2nodes to behave honestly.
1) Administration Client: The administration client is used
by the VA (i) to generate the election conﬁguration and
post it on the DPBB, (ii) authenticating voters’ identities
that were posted during the registration phase, (iii) and then
add authenticated, eligible voters to the list on the PBB, (iv)
Full No de
Voter Cli ent
Admi nistr ation
Verifier Client Full No de
DPBB Netwo rkClient s
Extern al Systems
Fig. 3: Æternum System Architecture.
compute polynomial coefﬁcients and post it to the DPBB, and
(v) deﬁne the election generator and post it to the DPBB.
2) Voter Client: The voter client allows voters to (i) Gener-
ate private and public credentials and post the public credential
to the DPBB, (ii) Check the list of eligible voters for the
inclusion of their own public credential, and (iii) Generate
and send all necessary parts of a ballot (election credential,
commitments, ZKPs, and vote) to the DPBB.
3) Veriﬁer Client: The veriﬁer client allows anyone to
verify the correctness of the credential polynomial and the
ﬁnal voting result. Veriﬁcation is done by re-calculating the
polynomial and the election result and comparing it to the
ones published on the DPBB. The veriﬁer client can (i)
Calculate the credential polynomial from the list of eligible
voters and compare it to the published polynomial, and (ii)
Verify all ballots, calculate the election result and compare it
to the published result. While the prototype implementation
does not provide a separate veriﬁer client, the functionality is
implemented in the voter client.
4) External Systems: A suitable Identity Management sys-
tem (IdM) and a CRS setup system are external systems. The
IdM provides Æternum with information about the eligibility
of voters (cf. Section III-A A1), while the CRS setup system
is an abstraction of the mechanism needed to generate a CRS
as a basis for the group generators (cf. Section III-A A6).
Previous assumptions as of Section III-A are now consid-
ered to determine relevant properties in detail.
A. Identity Management
REV schemes often make use of cryptographic signatures to
authenticate encrypted ballots  in order to achieve eligibil-
ity veriﬁability. In Æternum, ballots are not cryptographically
signed. If a voter would sign the plaintext ballot, BP is no
longer fulﬁlled i.e., UP is defeated. Still, Æternum requires a
suitable IdM for the registration step to verify eligibility. In the
current implementation, a voter identity, i.e., a key pair, has to
be created ad hoc on the voter’s machine. The public key pair
would then have to be registered in an IdM system, presumably
controlled by the VAs, to which the PBB has access.
During registration, the voter signs the registration transac-
tion with the private key of the identity. The PBB can check if
the signature belongs to one of the eligible voters in the IdM
system. If successful, the public credential uin the registration
transaction is stored in the list of eligible voters. This creates
a connection between voter identity and ubut does not pose a
threat to the privacy because uis not revealed when casting the
vote. Therefore, any IdM system can be used with Æternum
to add eligibility veriﬁcation.
B. Legal Dimensions
Depending on the legal jurisdiction Æternum is deployed
in, various data protection regulations, or regulations regarding
REV systems have to be considered. The two major examples
are the Swiss Federal Chancellery Ordinance on Electronic
Voting (VEleS) , and on a European level, the General
Data Protection Regulation (GDPR). Both pose legal chal-
lenges for Æternum and its DPBB, since the GDPR applies
to anyone processing or controlling the processing of personal
data , while the VEleS explicitly states trustworthiness
assumptions, and also demands speciﬁc requirements which
are currently not covered by Æternum and its voting scheme
(e.g., End-to-End Veriﬁability).
Further, the applicability of the GDPR to Æternum depends
on the use case. If the system is used in public elections,
Art. 17 (3) (d) could apply, which means that the voter does
not have the right to erasure because the data is needed
for achieving purposes in the public interest . In private
use cases, the matter is less clear. The major private data
connected to the voter is her identity and public credential
registered in the protocol’s registration phase. Due to the
nature of Æternum’s voting scheme, the DPBB does not store
identifying information with the ballots i.e., the ballots may
count as anonymous data according to the GDPR.
C. Unconditional Privacy
Even though the voter authenticates during the registration
phase, during the voting phase, only perfectly hiding com-
mitments are published. The commitments to α,βand uare
perfectly hiding Pedersen commitments . No information
about α,β, and ucan be gained from the commitments, even if
the discrete logarithm assumption is broken in the future. The
election credential is deﬁned as ˆu=ˆ
hβand thus, if the discrete
logarithm assumption breaks, βcan be calculated. Because
2is like a perfectly hiding commitment to βwith
randomness α, an adversary cannot decide to which uthe β
belongs without also knowing α. Furthermore, all ZKPs are
perfectly zero-knowledge i.e., no additional information can
be gained from them apart from the knowledge they prove.
Æternum provides IV, since the voter can query the PBB to
ﬁnd out if the ballot was recorded correctly. However, this as-
sumes that the voter’s platform is trusted, i.e., not infected with
malware corrupting the voter’s view of the PBB, and thus, not
providing any voting veriﬁcation mechanism . Malware on
the voter’s device can intercept all communications between
the voter and the DPBB, thereby modifying the voter’s ballot
and reﬂecting an incorrect state of the DPBB in order to keep
the voter from noticing the modiﬁcations. Hence, IV can only
be provided if we assume a trusted platform on the voter’s side,
but this is impractical. A more practical solution that gives
some relief to the problem is to have the voter Challenge-or-
Cast the ballot with a second independent device . Also
note that the querying of the DPBB for a speciﬁc ballot should
only happen over a non-anonymous channel (same as casting
the ballot). This would compromise the link between identity
of the voter and a speciﬁc ballot. Instead, the voter should
either query a subset, or the full set of ballots, while using an
Æternum provides UV because anyone can calculate the
election result. However, because ballots cannot be linked to
speciﬁc voters, it is fundamental that eligibility is ensured.
This is at the core of the voting scheme, and the purpose of
the proof transcripts π1,π2and π3, proving that the voter is
(i) in the set of eligible voters, (ii) the voter possesses the
private credentials behind the public credential, and (iii) that
the same private credentials were used to produce the election
credential. To successfully cast a fake ballot, an attacker would
have to ﬁnd αand βfor some hα
impossible for a present adversary because of the discrete
logarithm assumption. The other option is to construct a proof
without knowing αand β. This is impossible for a present
adversary because the proofs are computationally sound.
The property of Fairness in REV systems describes principle
that no partial tally can be derived before the ofﬁcial end
of the vote casting period, since an intermediate result could
inﬂuence voters who have not cast their ballot yet. The voting
scheme does not provide fairness by default. All votes are
posted to the DPBB in plaintext, allowing anyone to calculate
intermediary election results at any time in the voting period.
However, fairness can be achieved by encrypting the vote
with a public key provided by the VAs. The corresponding
private key should be a shared secret amongst the VAs to
distribute trust. Once the voting period is over, the private
key can be published on the DPBB, giving everyone the
ability to decrypt the votes. Note that the distributed trust
needed for fairness does not affect UP. Alternatively, Time-
lock encryption could be employed, allowing the encryption
to be locked for a speciﬁc time-period, without the need for
distributed key generation .
VI. SECURITY ANALYS IS
Only a detailed security analysis, including Æternum’s
threat model, an analysis of the protocol parameters, and their
security level can reveal risks and threat events. Due to space
restrictions the threat model and security analysis focuses on
the most relevant aspects of Æternum.
A. Threat Model
The adversaries are differentiated into a present and a future
adversary. A global and unbounded adversary is not considered
here but considered in . The threat model is congruent
with one of the utilized voting scheme . The present
adversary is active during the voting period i.e., at the time
an election occurs. A present adversary is bounded by today’s
computational resources available. Thus, it is assumed that
the present adversary is computationally bound. For instance,
the adversary cannot efﬁciently factorize primes, and thus
cryptographic primitives based on prime factorization are
considered secure. In contrast, the future adversary has access
to future, much more powerful computational resources i.e.,
may have access to a Quantum Computer (QC) , which
will make today’s infeasible problems possible to solve.
Æternum provides UP against future adversaries. However,
the veriﬁability properties during a voting period rely on the
hardness of ﬁnding αand βfor some hα
is impossible for a present adversary because of the discrete
logarithm assumption. The other option is to construct a proof
without knowing αand β. Still, that is impossible for a present
adversary because the proofs are computationally sound.
B. Protocol Parameters
Æternum’s voting scheme relies on the deﬁnition of the
two groups Gp,Gq, and their generators, which have to be
deﬁned and published on the DPBB before execution of the
registration protocol. The VA can publish the generators as
long as it is guaranteed that the relative discrete logarithms of
the generators are not known to anyone i.e., the generators
are independent, otherwise the Pedersen commitments are
not binding. For example, by knowing the relative discrete
logarithm x=logg1(g2), one can come up with an alternative
opening (α0, β0)for commitment comp(α, β ) = gα
replacing g2with gx
1, giving comp(α, β) = gα
1and then ﬁnding α0+xβ0=α+xβ. For
instance, an adversary breaking this assumption is able to cast
multiple valid votes with only one registered public credential,
because it would be possible to generate multiple valid private
credentials corresponding to that public credential.
Therefore, Æternum does not require trust in a single
party, but generators have to be instantiated in a distributed
manner. A possible solution is based on a Common Reference
String (CRS) from which generators can be derived. However,
producing a CRS without trust in one entity introduces more
complexity, as can be seen at the example of a multi-party
protocol being designed for the setup of a CRS for ZCash .
Nonetheless, such a multi-party ceremony might be necessary
for a voting system to fully achieve its privacy properties.
C. Security Level
Æternum’s veriﬁability depends on computational in-
tractability only during an on-going election. Thus, protocol
parameters have to be conﬁgured such that a current adversary
is unable to break the scheme during the vote casting period. In
case of weak parameters an adversary can ﬁnd α0and β0such
that for some public credential of an eligible voter u=gα0
. With these credentials, the attacker can post a ballot, i.e.,
produce valid NIZKPs, like any other eligible voter. Therefore,
the modulus and order of the groups Gpand Gqhave to be
chosen large enough to thwart such attacks. Also, the security
parameter κused in proof π2needs to be large enough to
guarantee the soundness of the proof, i.e., the prover must not
be able to make a veriﬁer accept a wrong statement.
TABLE II: Cryptoperiods’ Security Level Recommendations
Legacy use 80 160 1,024 80
2019 - 2030 112 224 2,048 112
beyond 2030 128 256 3,092 128
In Table II, the recommendations of the National Institute
of Standards and Technology (NIST) , compare different
choices for the security parameter κand the groups’ order
and modulus. Numbers in the order and modulus columns are
denoted in bit lengths. E.g., for a security level of 80, the
group modulus should be a prime of 1024 bit length. The
order of the group Gqdetermines the security of the private
credentials α, β.I.e., the size of the order is the size of the
keyspace for the credentials. Therefore the order’s bit size
is derived from recommendations on key size for DL-based
cryptosystems . A security level of 80 is not considered
secure anymore by NIST . However, because Æternum only
assumes computational intractability for the time of an on-
going election, a security level of 80 is probably still enough
at the time of writing. Otherwise, NIST recommends using a
security level of at least 112 starting from 2019.
D. Timing of Proof Veriﬁcation
The ballots’ NIZKPs are either (i) veriﬁed when the ballot
reaches the PBB or (ii) done after the vote casting phase
is concluded, and the DPBB stores all incoming ballots
without checking the proofs. In (i), the proof veriﬁcation’s
computational intensity puts a heavy load on the DL nodes,
and the consensus mechanism Denial of service (DoS) attacks
are easily performed and hard to mitigate. In (ii), anyone
is allowed to post any number of invalid ballots, which
allows ﬂooding of the DPBB with invalid ballots. Partial proof
veriﬁcation is not a viable approach. Proofs π1and π2are both
essential in checking if a ballot comes from an eligible voter
and if the sender of the ballot possesses the private credentials
corresponding to that voter’s public credential.
In order to mitigate ﬂooding of invalid ballots and keep
them from reaching consensus nodes, full nodes always run the
proof veriﬁcation on ballots before further broadcasting them
through the network. If a ballot is found to be invalid, it can
be dropped immediately at any node, thereby not amplifying
invalid ballot ﬂooding. Still, veriﬁcation on a valid ballot has to
happen at every node receiving it. Relying on the approval of
only one node is not acceptable in a decentralized DL setting.
E. Casting Multiple Ballots
The voting scheme  allows voters to cast multiple ballots
that are resolved either immediately or later in the tallying
phase. The current implementation of Æternum does not allow
for this to prevent replay attacks by checking, whether the
ballot’s election credentials were already used in another
ballot. Thus, the PBB does not have to run through the full
proof veriﬁcation. It is guaranteed that the eligible voter will
be the ﬁrst to use the election credential ˆu=ˆ
only she knows the private credential β. Only after a ballot
with that ˆuhas been posted an attacker will be able to replay
ballots with the same ˆu.
F. Insecure Voter Platform
A crucial aspect of REV systems is considering the voter
devices and the property of Cast-as-Intended Veriﬁability .
A compromised voter client presents various threat events
caused by malware (i) blocking vote broadcasting (and not
posting to the DPBB), (ii) changing the vote selection (iii)
breaking ballot secrecy by leaking the voter’s choice and
identity. While threat events (i) and (iii) are possible with
malware outside of the voter client application, threat event
(ii) requires that the attacker successfully modiﬁed the voter
client executable itself. Threat events (i) and (ii) can both
be detected by verifying the DPBB, which requires the voter
to use a second device to connect to the DPBB. For threat
event (iii), no countermeasures exist in the voting scheme of
Æternum. Once a voting client device is compromised, the
attacker can link any ballot produced with that device to the
owner. Protocol extensions presented in  can mitigate the
problem but is not yet part of Æternum.
The trust assumptions of Æternum complicate the practical
deployment of voter client applications. If the voters accept an
application distributed by the VA, blindly trusting that software
client’s integrity is not optimal, even if it was built from an
open-source code base. Veriﬁcation mechanisms need to be set
up that enable anyone to build the voter client and compare
the binary to the application distributed by the VA.
G. Malicious Network Participants
Even though the current consensus of the DPBB requires
at least two-thirds of all consensus nodes to be honest (i.e., is
BFT-based), individual malicious nodes can cause disruptions.
For instance, a malicious node can censor incoming trans-
actions. However, due to the anonymous channel voters are
not identiﬁable and cannot be targeted individually. Still, in
the registration phase, a node can effectively block a speciﬁc
voter’s attempt to register by dropping transactions received
from that voter. As a simple mitigation the voter’s client should
verify the correct inclusion of the registration transaction.
Another possible censorship is to provide false information. A
DPBB node can, e.g., respond with false protocol parameters
to a voter’s requests. In consequence, the voter will create
her credentials based on false groups and generators. In the
best case, these credentials will be rejected when posted to
the DPBB and, in the worst case, might go unnoticed, if the
public credential is also an element of the correct group. In
the latter case, the voter will think she registered successfully,
but will not be able to generate a valid ballot in the casting
phase, excluding her from the election.
However, these issues can be solved by running a local full-
node of the DPBB, which implements censorship prevention
mechanisms as well as query result veriﬁcation mechanisms.
Censorship resistance is achieved by choosing multiple peers
over a so-called peer selection algorithm and sending the
transaction to each selected peer. Queries, on the other hand,
are executed against the locally kept DL state, and thus no
trust in remote nodes is needed. The drawback of running a
full-node instead of connecting to a remote node is increasing
resource (disk storage, bandwidth, CPU) requirements. Many
BCs and DLs provide so-called light nodes, which consid-
erably reduce these requirements, while still providing high
censorship resistance and query result correctness guarantees.
VII. PERFORMANCE ANALYSI S
The ballot transaction is the central transaction for Æternum
because it contains the vote. The computations related to
the ZKPs affect both the voter client and the DPBB. The
voting client generates the NIZKPs, and the DPBB veriﬁes
them. Although the voting scheme  does not specify
that the proof transcripts have to be veriﬁed by the PBB,
validating transactions avoids the PBB getting stuffed with
invalid ballots. The performance of the NIZKP generation (cf.
Table III) and veriﬁcation (cf. Table IV) was evaluated with
three different scenarios (averaged over 100 executions) with
varying electorate sizes Nof 100, 1,000, and 10,000. Those
numbers were selected considering the typical distribution
of citizens within cantons in Switzerland, with the average
number of residents per municipality being 3,880 . In each
scenario, the required number of voter credentials were created
and registered on the DPBB. Then, the credential polynomial
was fetched from the DPBB, and ballots were created for
each voter. The protocol parameters were chosen to provide
a security level of 80 (see Section VI-C). For performance
measurement, two consensus nodes, one for the voter and one
for the VA, were deployed as Docker containers. Voter and VA
clients were launched on the same machine for all transactions.
The performance tests were run on a virtual machine with eight
2.4 GHz Intel Xeon E312xx CPUs, 16 GB RAM, running on
Ubuntu 18.04.4. Tendermint recommends at least 2GB RAM
and a 2 GHz CPU with two cores.
TABLE III: Average Proof Generation Time [ms]
Electorate Size N π1π2π3Total
100 105 513 1.66 619.66
1,000 292 581 1.65 874.65
10,000 1,574 579 1.63 2,154.63
Table III depicts the average time for the NIZKP generation
per voter. Proof π1is the set membership proof, π2is the proof
of known representations (of committed value) and π3is the
proof of known equality (of discrete logarithms). Effort spent
on π3is negligible, whereas proof π2takes a constant amount
TABLE IV: Average Proof Veriﬁcation Time [ms]
Electorate Size N π1π2π3Total
100 64 431 2.24 497.24
1,000 115 479 2.36 596.36
10,000 243 482 2.57 727.57
of time, largely unaffected by the increased electorate size. As
mentioned, π2is only dependent on the security parameter κ.
Increasing the security level of π2by increasing κwill make
the time needed for proof generation grow linearly with κ.
In Table’s III column Total, results for the proof generation
of all three proofs are compared to the results achieved in
. There, the poof generation took 1.4, 1.6, and 3 seconds
for an electorate of 100, 1,000, and 10,000, respectively. Both
UniCrypt and Æternum do not apply any speciﬁc optimiza-
tions to the proof generation. In , an optimized version of
the proof π1is evaluated, which achieves signiﬁcantly lower
execution times. However, the evaluation is based on a smaller
order pfor Gpof 256 bit and a larger modulus oof 1,536 bit,
compared to 1,024 and 1,034 bit with Æternum’s evaluation.
VIII. REL ATED WO RK
REV systems were used in various electoral processes
around the world e.g., Estonia , Switzerland , Aus-
tralia  and Norway . Due to conﬂicting privacy and
veriﬁability requirements , none of the existing voting
systems managed to solve all challenges in REV . Most
systems focus on veriﬁability and do not consider Everlasting
BP as main concern . REV systems use cryptographic
instruments to achieve the required properties .
TABLE V: Comparison of Selected Related Work
Helios  7X7X
Provotum 2.0  X7 7 X
Koinonia  7X7X
Æternum X X X X
As shown in Tab. V, only Provotum 2.0  also provides a
DPBB, while Helios and Koinonia use centralized servers as
a PBB. In , an enhancement to Helios  is proposed,
where a second channel between the voter and the Helios
server is introduced. The encrypted ballot is not published
publicly anymore, but only available to the Helios server.
Instead, a second message with a Pedersen commitment of
the ballot is published. Therefore, Everlasting BP is based on
the fact that an adversary does not have access to the encrypted
ballots anymore. In , Consistent Commitment Encryption
is proposed, which allows the VA to derive commitments
from encrypted ballots. Similar to , only the commitments
are publicly available, while the encrypted ballots are only
visible to the VA. Everlasting BP is provided to the public,
but not to the VA. In , the approach of Helios is combined
with a mix-net, removing the voter identities from the votes.
The difference from a usual mix-net approach is that two
separate mixes are performed simultaneously, a private one
that shufﬂes the encrypted ballots and a public one that shufﬂes
commitments to those ballots.
A ﬁrst scheme providing Unconditional BP is . The
scheme is self-tallying and only intended for small boardroom
elections because it is data intensive. Every voter needs to
generate and post data of size linear to the number of partic-
ipating voters. In , a more efﬁcient approach is proposed.
However, voters need to take turns casting their ballots, each
taking the current state of the election. For this scheme to
work, each voter has to use the public keys for all other voters,
which limits the protocol’s scalability. Also, both  and
 depend on the discrete logarithm assumption for their
BP. Therefore, they do not provide everlasting BP and do not
reach unconditional BP.
In order to achieve UP in Æternum, an Anonymous Channel
(AC) is required, i.e., vote casting and vote querying require
an AC. Even though the ballot does not leak any information
about the voter, an adversary can perform Trafﬁc Analysis
(TA) on the network during vote casting or querying. The
privacy of the communication between the voter and the DPBB
is crucial, and suitable solutions require evaluation. In Table
VI, an overview of AC protocols is provided .
TABLE VI: Anonymous Communication Protocols 
Routing Class Adversary Challenges
Mixnet Global, Active TA (e.g., ﬂooding)
Onion Routing Local, Active TA (e.g., timing)
Random Walks Local, Active Partitioning Attacks
DCNet Global, Passive Collision and Disruption
MNs were introduced in  and aggregate input messages
into batches, shufﬂe these messages, and output them in a
reshufﬂed form, which removes the relation between input
and output messages, disabling the ability to correlate mes-
sages . MNs are vulnerable to collusion (of mixers) and
to ﬂooding attacks (e.g., if there are not enough honest users).
Resilience against TA comes at the price of high latency, which
makes them suitable for application in electronic mail .
An onion routing network is formed by Onion Routers (OR),
which form a bidirectional channel (so-called circuit) between
Users, which choose an ordered sequence of ORs and establish
a circuit. Then, users encrypt the data in a layered fashion,
and each OR in the circuit can decrypt their corresponding
layer, forwarding to the next OR. Onion routing protocols,
such as Tor  have low computational overhead and are thus
suitable for low-latency applications (e.g., Web browsing) .
However, OR is only considered secure against local, active
adversaries and is vulnerable to TA attacks . Additional
routing classes are Random Walks based on Distributed Hash
Tables (DHT), as well as Dining Cryptographers Networks
(DCNets). Depending on the threat model (e.g., global or local
adversary) for the speciﬁc use case where Æternum is applied,
an appropriate anonymous channel needs to be selected.
IX. CONCLUSIONS AND FUTURE WORK
This paper introduced Æternum, a decentralized voting sys-
tem, which does not assume any computational intractability
and does not require a Trusted Third Party (TTP) or central
Concluding, Æternum achieves Unconditional Privacy (UP),
secured against future adversaries. While other voting
schemes’ privacy is vulnerable to future adversaries, Æternum
provides UP by utilizing the voting scheme from . Æter-
num only requires strong parameters for veriﬁability during the
voting period. Additionally, Æternum utilizes a Decentralized
Public Bulletin Board (DPBB), which is implemented as
a public permissioned Distributed Ledger (DL). A publicly
readable DL enables anyone to verify the DL’s election data
(i.e., the NIZKPs) and compute the ﬁnal tally. Further, the
DL-based architecture allows for a transparent selection of au-
thorized Voting Authorities (VA) (e.g., authorities or consortia
members), which participate in the DL network consensus.
Furthermore, measurements indicate that the main perfor-
mance bottleneck of Æternum is the computational effort
required to generate and verify the ballots’ NIZKPs (π1,π2,
π3). Thus, for nation-wide voting and elections, VAs serve as
a TTP, and Æternum’s trust assumptions may not be needed.
Nevertheless, for use-cases without such structures established
and without a central, trusted VA, Æternum provides a suitable
alternative. A set of stakeholders can set up and run an election
without requiring trust in each other for ballot secrecy.
E.g., an open-source community with the need for com-
munity decisions can invite community members to apply as
consensus nodes for the DPBB. With a sufﬁcient amount of
independent participants, the DPBB’s safety and integrity are
assured. The same participants can take part in the distributed
setup of protocol parameters. Although a prominent actor
is required to initialize the DPBB and set the agreed upon
parameters, all actions made by that actor are publicly visible
and malicious behavior is clearly detectable.
Possible future work includes (i) the integration of a suit-
able anonymous channel, which could be executed within
Æternum’s DPBB network directly, and (ii) the design of a
suitable Multi-Party Computation for the CRS setup. Further-
more, (iii) performance optimizations of the set membership
proof  need to be considered for large electorates (e.g.,
country-wide deployments). Also, (iv), future work includes
the extension of Æternum with Receipt-Freeness, as proposed
in . Lastly, the current implementation’s availability is not
bolstered against DoS attacks, and mitigations are possible
future work. (e.g., Only allowing a single, cryptographically
signed vote transaction per ˆu).
ACK NOWLED GE ME NT S
This paper was supported partially by (a) the University
urich UZH, Switzerland, and (b) the European Union’s
Horizon 2020 Research and Innovation Program under Grant
Agreement No. 830927, the CONCORDIA project.
 B. Adida, “Github: Helios Voting Server.” [Online]. Available:
 ——, “Helios: Web-based open-audit voting,” in Proceedings of the 17th
USENIX Security Symposium, 2008.
 E. Barker, “Recommendation for Key Management – Part 1: General,”
pp. 1–142, 2016. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/
 K. Bauer, D. McCoy, D. Grunwald, T. Kohno, and D. Sicker, “Low-
resource routing attacks against Tor,” WPES’07 - Proceedings of the
2007 ACM Workshop on Privacy in Electronic Society, pp. 11–20, 2007.
 S. Bayer and J. Groth, “Zero-knowledge argument for polynomial
evaluation with application to blacklists,” Lecture Notes in Computer
Science, Vol. 7881 LNCS, pp. 646–663, 2013.
 J. Benaloh, R. Rivest, P. Ryan, P. Stark, V. Teague, and P. Vora, “End-
to-end veriﬁability,” 2015.
 D. Bernhard, V. Cortier, O. Pereira, B. Smyth, and B. Warinschi,
“Adapting helios for provable ballot privacy,” Lecture Notes in Computer
Science, Vol. 6879 LNCS, pp. 335–354, 2011.
 S. Bowe, A. Gabizon, and M. D. Green, “A multi-party protocol
for constructing the public parameters of the Pinocchio zk-SNARK,”
Lecture Notes in Computer Science, Vol. 10958 LNCS, pp. 64–77, 2019.
 J. Buchmann, D. Demirel, and J. V. D. Graaf, “Towards a Publicly-
Veriﬁable Mix-Net Providing,” Financial Cryptography and Data Se-
curity. FC 2013. Lecture Notes in Computer Science, Vol. 7859, pp.
 Bundesamt f ¨
ur Statistik, “Regionalportr¨
ats 2020: Kennzahlen aller
Gemeinden,” 2020. [Online]. Available: https://bcbev.ch/bfs-gemeinde
 S. Bundeskanzlei, “Verordnung der BK ¨
uber die elektronische
Stimmabgabe (VEleS),” 2013. [Online]. Available: https://www.admin.
 J. E. Burge and D. C. Brown, “Software Engineering Using
RATionale,” Journal of Systems and Software, Vol. 81, No. 3,
pp. 395–413, 2008. [Online]. Available: http://www.sciencedirect.com/
 D. L. Chaum, “Untraceable Electronic Mail, Return Addresses, and
Digital Pseudonyms,” Communications of the ACM, 1981.
 L. Chen, S. Jordan, Y.-K. Liu, D. Moody, R. Peralta, R. Perlner, and
D. Smith-Tone, “Review on Post-Quantum Cryptography,” NIST, Tech.
Rep. NISTIR 8105.
 Cosmos SDK, “Documentation: Staking Module.” [Online]. Available:
 E. Cuvelier, O. Pereira, and T. Peters, “Election veriﬁability or ballot
privacy: Do we need to choose?” Lecture Notes in Computer Science,
Vol. 8134 LNCS, pp. 481–498, 2013.
 D. Demirel, J. V. D. Graaf, and R. Ara ´
ujo, “Improving Helios
with Everlasting Privacy Towards the Public,” EVT/WOTE’12
Proceedings of the 2012 international conference on Electronic
Voting Technology/Workshop on Trustworthy Elections, 2012.
[Online]. Available: https://www.usenix.org/system/ﬁles/conference/
 R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The Second-
Generation Onion Router,” in Proceedings of the 13th Conference on
USENIX Security Symposium - Volume 13, ser. SSYM’04. USA:
USENIX Association, 2004, p. 21.
 M. Eck, A. Scheitlin, and N. Zaugg, “Github: Provotum 2.0.” [Online].
 Estonian National Electoral Committee, “E-Voting System General
Overview,” Tallinn, 2005.
 European Parliament and The Council of the EU, “Regulation (EU)
2016/679 of the European Parliament and of the Council of 27 April
2016,” 2016. [Online]. Available: https://gdpr-info.eu/
 H. Ge, “Github: Koinonia.” [Online]. Available: https://github.com/
 H. Ge, S. Y. Chau, V. E. Gonsalves, H. Li, T. Wang, X. Zou, and N. Li,
“Koinonia: Veriﬁable E-Voting with Long-term Privacy,” pp. 270–285,
 D. Giry and BlueKrypt, “Cryptographic Key Length Recommendation,”
2020. [Online]. Available: https://www.keylength.com/
 J. Groth, “Efﬁcient maximal privacy in boardroom voting and anony-
mous broadcast,” Lecture Notes in Computer Science, Vol. 3110, pp.
 J. A. Halderman and V. Teague, “The New South Wales iVote system:
Security Failures and Veriﬁcation Flaws in a Live Online Election,” in
Lecture Notes in Computer Science (including subseries Lecture Notes
in Artiﬁcial Intelligence and Lecture Notes in Bioinformatics), Vol. 9269,
2015, pp. 35–53.
 H. Jonker, S. Mauw, and J. Pang, “Privacy and Veriﬁability in Voting
Systems: Methods, Developments and Trends,” Computer Science Re-
 A. Kiayias and M. Yung, “Self-tallying Elections and Perfect Ballot
Secrecy,” PKC’02, 5th Interna- tional Workshop on Theory and Practice
in Public Key Cryptography, LNCS, Vol. 2274, pp. 141–158, 2002.
 C. Killer, B. Rodrigues, R. Matile, E. Scheid, and B. Stiller, “Design and
Implementation of Cast-as-Intended Veriﬁability for a Blockchain-based
Voting System,” in 35th Annual ACM Symposium on Applied Computing
(SAC ’20). Brno, Czech Republic: ACM, 3 2020, pp. 286–293.
[Online]. Available: https://dl.acm.org/doi/10.1145/3341105.3373884
 C. Killer, B. Rodrigues, E. J. Scheid, M. Franco, M. Eck, N. Zaugg,
A. Scheitlin, and B. Stiller, “Provotum: A Blockchain-Based and End-
to-End Veriﬁable Remote Electronic Voting System,” in IEEE 45th
Conference on Local Computer Networks (LCN). Sidney, Australia:
IEEE, 11 2020.
 C. Killer and B. Stiller, “The Swiss Postal Voting Process and Its
System and Security Analysis,” 2019, pp. 134–149. [Online]. Available:
http://link.springer.com/10.1007/978-3-030- 30625-0 9
 S. Kremer, M. Ryan, and B. Smyth, “Election Veriﬁability in Electronic
Voting Protocols,” in ESORICS, ser. Lecture Notes in Computer Science,
Vol. 6345. Springer, 2010, pp. 389–404.
 R. Krimmer, D. Duenas-Cid, I. Krivonosova, P. Vinkel, and A. Koitmae,
“How Much Does an e-Vote Cost? Cost Comparison per Vote in
Multichannel Elections in Estonia,” Electronic Voting. E-Vote-ID 2018.
Lecture Notes in Computer Science, Vol. 11143, pp. 117–131, 2018.
 O. Kulyk, J. Henzel, K. Renaud, and M. Volkamer, “Comparing
“Challenge-Based” and “Code-Based” Internet Voting Veriﬁcation Im-
plementations,” in Human-Computer Interaction – INTERACT 2019,
D. Lamas, F. Loizides, L. Nacke, H. Petrie, M. Winckler, and P. Zaphiris,
Eds. Cham: Springer International Publishing, 2019, pp. 519–538.
 J. Liu, T. Jager, S. A. Kakvi, and B. Warinschi, “How to
build time-lock encryption,” Designs, Codes, and Cryptography,
Vol. 86, No. 11, pp. 2549–2586, 2018. [Online]. Available: https:
 P. Locher, “Unconditional Privacy in Remote Electronic Voting Theory
and Practice,” Ph.D. dissertation, University of Fribourg, 2016.
 P. Locher and R. Haenni, “Veriﬁable Internet Elections with Everlasting
Privacy and Minimal Trust,” Lecture Notes in Computer Science, Vol.
9269, pp. 74–91, 2015.
 ——, “Receipt-free remote electronic elections with everlasting privacy,”
Annales des Telecommunications/Annals of Telecommunications, 2016.
 T. Moran and M. Naor, “Receipt-free universally-veriﬁable voting with
everlasting privacy,” Advances in Cryptology - CRYPTO 2006, Vol.
LNCS 4117, pp. 373–392, 2006.
 C. Mueller, “Github: Aeternum - UP Voting System.” [Online].
 T. P. Pedersen, “Non-interactive and information-theoretic secure ver-
iﬁable secret sharing,” Lecture Notes in Computer Science, Vol. 576
LNCS, pp. 129–140, 1992.
 K. Sako and J. Kilian, “Receipt-free Mix-type Voting Scheme - A
Practical Solution to the Implementation of a Voting Booth,” Lecture
Notes in Computer Science, Vol. 921, pp. 393–403, 1995.
 U. Serdult, M. Germann, F. Mendez, A. Portenier, and C. Wellig,
“Fifteen years of internet voting in Switzerland: History, Governance
and Use,” 2015 2nd International Conference on eDemocracy and
eGovernment, ICEDEG 2015, pp. 126–132, 2015.
 F. Shirazi, M. Simeonovski, M. R. Asghar, M. Backes, and C. Diaz,
“A survey on routing in anonymous communication protocols,” ACM
Computing Surveys, Vol. 51, No. 3, 2018.
 P. Vinkel, “Internet voting in Estonia,” Information Security Technology
for Applications. NordSec 2011. Lecture Notes in Computer Science,
Vol. 7161, pp. 4–12, 2012.
 P. Voigt and A. v. d. Bussche, The EU General Data Protection
Regulation (GDPR): A Practical Guide, 1st ed. Springer Publishing
Company, Incorporated, 2017.
All links provided above were last accessed on March 09, 2021.