Sequent

What Is Homomorphic Tallying?

Serhii Bohynia — Wed, 03 Apr 2024 14:54:07 +0000

Voting systems based on homomorphic tallying leverage the power of encryption’s homomorphic property to compute tallies. This unique property enables the addition of encrypted numbers without decryption. By applying this technique to voting, we can compute election results without decrypting individual votes, ensuring the secrecy of each ballot. However, there are challenges to overcome. We need to encode voter selections in a way compatible with summing, typically using vectors of ciphertexts where 1 represents a marked option and 0 represents an unmarked one. Additionally, we must ensure that the encrypted choices are valid, guarding against nonsensical or maliciously constructed ballots. Zero-knowledge proofs play a crucial role in verifying ballot validity while preserving ballot contents’ confidentiality.

Glossary

What Is Homomorphic Tallying?

The post What Is Homomorphic Tallying? appeared first on Sequent.

What Is End-To-End Verifiable Voting?

Serhii Bohynia — Wed, 03 Apr 2024 13:28:29 +0000

End-to-end auditable or end-to-end voter-verifiable (E2E) voting systems have a high level of integrity and are resistant to tampering. E2E verifiability means that all the processes necessary for the integrity of an election can be verified online. Essentially, the system can prove that all steps of the election were correctly completed.

End-to-end verifiability (E2E) in online voting refers to the ability of voters to verify that their vote has been recorded and counted accurately, without relying on the trustworthiness of any intermediary. In an E2E system, voters can verify that their vote has been accurately recorded and counted by checking the encrypted record of their vote against a public record of the final tally. This ensures that the integrity of the voting process is preserved, as voters can verify that their vote has been counted accurately without having to trust that the voting system or any other intermediaries have not tampered with the vote. E2E systems can help to increase confidence in the integrity of online voting and may be an important component of a secure online voting system.

Glossary

What Is End-To-End Verifiable Voting?

End-to-end auditable or end-to-end voter-verifiable (E2E) voting systems have a high level of integrity and are resistant to tampering.

E2E verifiability means that all the processes necessary for the integrity of an election can be verified online. Essentially, the system can prove that all steps of the election were correctly completed.

The post What Is End-To-End Verifiable Voting? appeared first on Sequent.

What are Online Voting Systems?

Serhii Bohynia — Wed, 03 Apr 2024 13:20:17 +0000

Online voting systems are websites or software programs that are designed to facilitate the process of online voting. Online voting systems may also be referred to as online elections, electronic voting systems, or e-voting systems. They provide governments and private organizations with a platform to conduct secure elections and votes. These systems typically provide a secure platform for voters to log in, view the available choices, and cast their votes. They may also include features such as voter authentication, vote tracking, and real-time results reporting. Online voting systems are designed to be user-friendly and easy to use, while also providing a high level of security to protect the integrity of the voting process.

Glossary

What are Online Voting Systems?

The post What are Online Voting Systems? appeared first on Sequent.

Blockchains and Bulletin Boards

Serhii Bohynia — Mon, 26 Jun 2023 08:21:36 +0000

Blog

Blockchains and Bulletin Boards

Blog, Technology

Add a header to begin generating the table of contents

Introduction

Bulletin boards play a vital role in ensuring the integrity and verifiability of cryptographically secure voting systems. Acting as a centralized storage system, the bulletin board serves as a transparent platform where all public information related to the election is openly published, enabling anyone to scrutinise, assess, and audit the process. In the realm of end-to-end verifiable voting systems, the bulletin board becomes even more significant as it holds crucial information required to validate the adherence to established protocols, confirm the accuracy of the reported results, and safeguard against any potential manipulation by administrators or other entities.

In a typical scenario, the bulletin board acts as a repository for various essential components of a voting system. It securely stores crucial information, including public keys and key generation specifics, records of voting events and encrypted votes, decryption and tally results, and robust mathematical proofs validating the accuracy of these elements. Moreover, the bulletin board assumes the role of an audit ledger, diligently logging significant events and actions, and providing a transparent record that can be accessed and reviewed by anyone seeking to ensure the system’s integrity.

There are some desirable properties that bulletin boards must have to better meet their objectives:

1. Distributed

In this way, elections can continue to be conducted despite DDOS attacks. In order to achieve this property, hard problems such as byzantine consensus and distribution engineering challenges must be resolved.

2. Chronological

Logging of events and data on the bulletin board should reflect the order in which they occur.

3. Tamper-Resistant

It should not be possible to manipulate results or remove records from the audit log by altering bulletin board records.

4. Publically Auditable

Information on bulletin boards should be auditable by anyone. Specifically, this property should be supportive of end-to-end verifiability.

5. Access Controlled and Authenticated

A bulletin board should include mechanisms for controlling what information can be posted, as well as digital signatures for information and receipts for certification.

In Summary

Developing a robust bulletin board using blockchain technologies could be a fascinating research project. As well as offering some support for signatures, blockchain technology seems particularly well suited to satisfy distribution, chronology, tamper resistance, and auditing needs. To ensure that the throughput is compatible with voting needs, efficiency considerations regarding the number of “transactions” per second would also need to be considered.

The post Blockchains and Bulletin Boards appeared first on Sequent.

Degree of Privacy in Voting

Serhii Bohynia — Tue, 30 May 2023 08:37:41 +0000

This article demonstrates the natural extension of Diaz’s 2002 degree of anonymity model to voting scenarios. The outcome is straightforward but holds potential value for intricate cases like weighted voting, where privacy concerns surpass the conventional “bisimilarity-under-swapping” definition outlined by Delaune in 2009. These concerns arise from the possibility of information leakage through election results, as highlighted in Delaune’s work:

Blog

Degree of Privacy in Voting

Blog, Research

Add a header to begin generating the table of contents

It is important to note that the definition of “bisimilarity-under-swapping” remains resilient even in scenarios where the outcome of the election necessitates the disclosure of votes from VA and VB. This applies to situations such as unanimous voting or when other voters reveal their choices, leading to the deduction of votes for VA and VB.

The notion that information can potentially leak from voting results directs our attention to the degree of anonymity model. This model, rooted in information theory, enables the quantification of anonymity provided by anonymous connection schemes. It considers attackers who gather probabilistic information about users. Unlike the standard possibilistic privacy definition for voting, the degree of information in this model pertains to probabilistic inference. The measure is not binary; instead, it quantifies the amount of information an attacker can obtain by observing the process. In the context of voting, as discussed later, the attacker acquires information by observing the results, which are accessible regardless of the existence of ballot privacy.

By quantifying information gain, entropy naturally results (Diaz 2009).

As a measure of degree of anonymity, the authors apply a normalization factor based on maximum entropy (zero information leakage):

Given the normalization

Extension to Voting

Using the degree of anonymity model, we can determine who sent a message out of possible groups (the anonymity set). This model should be extended to the case of voting, where the attacker wants to determine the voter’s choice. The availability of individual votes as plaintexts varies depending on the secure voting scheme employed. Consequently, the translation between different scenarios is not instantaneous. In one case, the focus is on determining a single variable out of n options, while in the context of voting, the objective is to ascertain vote choices based on election results.

However, it is possible to incorporate probabilities directly into the degree of anonymity model. These probabilities should be derived from the election results, as they constitute the publicly available information accessible to the attacker. Furthermore, it is desirable to establish a general approach that does not rely on the specific electoral method or the format of the election result. We start with:

These are sets of voters, choices and election results.

The function ‘a’ represents the individual voter’s selection, defined as a mapping that associates each voter with their respective choice. On the other hand, the function ‘t’ denotes the election tally, which maps the set of choices made by voters to the corresponding result.

Ar corresponds to the set of all functions ‘a’ that generate the outcome ‘r’, representing the sets of selections made by voters. Expanding on this, the function ‘m’ denotes the count of distinct functions ‘a’ in which voter ‘v’ selects choice ‘c’ and the overall result is ‘r’. In essence, it quantifies the number of instances where voter ‘v’ chooses ‘c’ and the final result corresponds to ‘r’.

These expressions allow us to provide equivalent expressions for the terms in the original definition of degree of anonymity. According to the election result, the entropy corresponding to the uncertainty of a voter’s choice is

In this case, entropy is simply the standard expression for entropy, but with probabilities that correspond to the likelihood that a certain choice will be selected given a certain election result. When there is no information about the election, the maximum entropy corresponds to a uniform probability distribution for the voter’s choice, resulting in

where |C| is the number of choices (the cardinality of C). Finally, the degree of privacy is

which quantifies the degree to which a voter’s v choice remains secret given the election result r. This expression exhibits similarities to the degree of anonymity model, albeit with certain modifications. Firstly, we are addressing the degree of privacy, quantifying the level of knowledge about a voter’s choice, rather than attempting to de-anonymize the sender of a message. Furthermore, this result pertains to each individual voter. While this characteristic may not always be relevant, it holds significance in scenarios involving weighted voting, where voters possess distinct degrees of anonymity. Additionally, it is possible to derive aggregate values, such as the average or minimum degree of anonymity. Another generalization involves computing expectation values over results for a given setup. As an extreme example, in an election with a single voter, the degree of anonymity would always be 0, regardless of the result.

As mentioned previously, the aforementioned definition applies universally to any election, regardless of the electoral method, result type, or even the design of the ballot. Now, let’s delve into some specific examples to further illustrate this point.

Examples

We calculate values for examples. In all cases we are using a plurality rule for the function t: V => C => R.

Yes/No vote, Single voter

This is a Yes/No vote (ballot options are Yes or No). We have a single voter, John.

V = { John }, C = { Yes, No }, R = { {Yes:1, No:0}, {Yes:0, No:1} }

In the following expression:

The value of n is 2, for two possible results (the cardinality of C). Consider the case where r = Yes, then

Ar = { (John, Yes) }, and |Ar| = 1

since it is the only way that John could have voted. Similarly,

m(John, Yes, Yes) = 1 and m(John, No, Yes) = 0

again, for the same reason. The entropy then reduces to

H(v, r) = 1/1*log(1/1) = 0

which when plugged into

gives

d(John, Yes) = d(John, No) = 0

The degree of anonymity is zero. This matches the obvious fact that in an election with a single voter, their vote will be revealed.

Yes/No vote, Unanimous result

V = { v1 … vn }, C = { Yes, No }, R = { {Yes:n, No:0}, {Yes:0, No:n} }

In the following expression:

we see that the unanimous vote case has a similar form as the case of a single voter, except for a general number of voters and results:

|Ar| = 1

for all r, and also

m(v, Yes, {Yes:0, No: 10} ) = 0 and m(v, Yes, {Yes:10, No: 0} ) = 1

which leads to

d(v, r) = 0

for all v and r. Once again, this matches the obvious expectation: in a unanimous election, all votes are disclosed.

Yes/No vote, General case

V = { v1 … vn }, C = { Yes, No }, R = { {Yes:n, No:0} … {Yes:0, No:n} }

In this case, the cardinality of R is |C|, as we are not confining the results solely to unanimous outcomes. The calculation for |Ar| and m deviates from the previous approach. By indexing the results in R based on the number of positive votes, we obtain the following:

with a binomial coefficient on the right. This is the number of ways it is possible to obtain the result r. We also have

dividing the previous two expressions provides

Because this is a Yes/No election

which when divided by |Ar|

The complete expression for H is therefore

at this point, we can do a couple of sanity checks. Firstly, the probabilities in the entropy expression (r/|C| + 1 — r/|C|) sum to 1. Secondly, these examples highlight a common-sense inference. If an election comprises |C| choices and the number of “Yes” votes is r, then the probability of any voter selecting “Yes” must be r / |C|. Although our generalized approach for calculating entropy is more extensive than our intuition for indistinguishable voters under the plurality rule, it aligns with logical reasoning.

Finally, the degree of privacy for the general Yes/No election is

Below is a graph of this function for a fixed value of 10 voters (|C| = 10).

As we saw in the previous section, unanimous elections correspond to the two edges of the graph, where d = 0.

Summary

The application of the generalized degree of anonymity model in the context of voting has demonstrated its versatility and relevance. This extension proves applicable to diverse voting methods, providing a flexible approach. Through simple yet illustrative examples, we observe that the model’s calculations align with outcomes derived from traditional methods specific to each type of election. While these initial examples may seem straightforward, the significance of the degree of privacy becomes particularly apparent in more complex scenarios where voters are distinguishable, and results may inadvertently reveal additional information. Weighted voting serves as a prime illustration of such cases. While the definitions presented herein can be equally applied to this scenario, employing them in their general form may require additional considerations to address potential combinatorial challenges.

References

Diaz 2002 — Towards measuring anonymity

Delaune 2009 — Verifying privacy-type properties of electronic voting protocols

[3] It is also possible to use a non-uniform prior probability here. In that case the resulting conditional probabilities must be derived in such a way that relative magnitudes are preserved.

The post Degree of Privacy in Voting appeared first on Sequent.

A Toy Model of Information – Theoretic Security

Serhii Bohynia — Fri, 21 Apr 2023 09:20:46 +0000

In a previous post, we discussed different types of uncertainty due to limited information or computations as the basis for cryptography. A Caesar cipher example demonstrated how an adversary could have all the information to reveal a secret if the relationship between the message space, key space, and ciphertext satisfies the following:

Blog

A Toy Model of Information – Theoretic Security

Blog, Research

Add a header to begin generating the table of contents

				
					ZHOO GRQH BRX KDYH IRXQG WKH VHFUHW YGNN FQPG AQW JCXG HQWPF VJG UGETGV
XFMM EPOF ZPV IBWF GPVOE UIF TFDSFU <strong>WELL DONE YOU HAVE FOUND
THE SECRET</strong> VDKK CNMD XNT GZUD ENTMC SGD RDBQDS UCJJ BMLC WMS
FYTC DMSLB RFC QCAPCR TBII ALKB VLR EXSB CLRKA QEB PBZOBQ

Since none of the other attempts yielded meaningful results, we were able to identify the correct message. Since the number of possible keys is so small, only one of them can decrypt a possible message. In technical terms, the key space and message space[2] are small enough compared to the length of the message that only one key will decrypt.

The situation can be coarsely be classified into three cases:

H(K | C) = H(K) — Perfect secrecy
H(K | C) < H(K) — Information-theoretic security
H(K | C) = 0 — Computational security

The epistemic uncertainty mentioned in the previous entry is the epistemic uncertainty of information theory. To illustrate how information-theoretic privacy works, we can use a simple model that reduces computation security when conditions are not met.

Elements of our model

The XOR function

Using a key that determines the exact transformation and allows the intended recipient to recover the secret, our toy model must specify how messages are encrypted from plaintext to ciphertext. We can use a two-character alphabet that consists of binary sequences as messages. As our encryption function, we will use the XOR function, which produces a third binary sequence from two inputs. By choosing this option, we also fix our key space to be binary sequences. Here’s an example encryption:

1010011000 XOR 1100111010 = 110100010

The XOR function produces a ciphertext 110100010 by taking as input a message (1010011000) and a key (1100111010). There is no difference in the process, we can simply imagine that the 1010011000 above is some meaningful content like “WELL DONE YOU FOUND THE SECRET ”. Like in English, in plaintext space (binary sequences) there is a subset of combinations that make meaningful messages, while the rest do not. As a result, we come to the notion of language entropy, which measures how large the meaningful subset of messages is in relation to the entire plaintext space.

As the language entropy increases, the proportion of the blue region in relation to the entire plaintext space also increases. For binary languages, the entropy ranges from 0 to 1, which is measured in bits per character. Currently, our toy model consists of these components:

Plaintext space: P ∈ {0, 1}n
Message space: M ⊂ P
Key space: K ⊂ {0, 1}n
Ciphertext space: C ∈ {0, 1}n
Encryption function: XOR: P x K → C
Language entropy: HL ∈ {0.0-1.0}

The security characteristics of our system are contingent upon three parameters that are associated with the aforementioned factors:

n:the number of characters in the plaintext
|K|: the size of the key space
HL: the language entropy
RL = 1 — HL: the language redundancy

The final parameter, redundancy, is essentially a rephrasing of the language entropy. The equation that formulates the security in relation to these parameters is:

The given equation provides a minimum estimate for the anticipated quantity of false keys, denoted by the term “sn”. A false key, for a specific ciphertext, is a key that decrypts the ciphertext into a message that is not equivalent to the message that was initially encrypted using the correct key. As illustrated in the initial encryption example mentioned in the post, it was observed that among all the attempted keys used to decrypt the ciphertext, only one produced a coherent plaintext, implying that the ciphertext had no false keys. Conversely, if one of the keys, denoted as “s”, had decrypted the ciphertext into something similar to

THE MESSAGE COULD BE THIS

then in such a scenario, the key “s” would be considered a false key. If an attacker were to attempt all possible keys, they would end up with two potential messages, making it challenging to determine the accurate one. As a result, the confidentiality of the secret would be relatively preserved. The presence and quantity of anticipated false keys determine the category to which a cryptosystem belongs among the three general classifications mentioned earlier. Examining the false key equation reveals the following patterns:

sn increases with the size of the key space, |K|
sn decreases with the size of the plaintext, n
sn decreases with language redundancy, RL

A visual representation

Encryption representation with n = 2, H = 0.8, M = 3, K = 1

The image’s left side depicts a visual representation of our parameter values for the toy model, where the left axis denotes the plaintext space, and the right axis represents the ciphertext space. Each point on the graph symbolizes an encryption or a mapping from the plaintext space to the ciphertext space. To obtain the visual representation, we set n = 2, resulting in a plaintext space with four elements. Out of these four, three convey meaningful messages, considering a language entropy of 0.8. Thus, the three red dots on the graph correspond to the three encryptions of these three meaningful messages. Since K=1, each plaintext has only one corresponding ciphertext or, visually, only one point on any given horizontal line. For comparison, see:

n = 2, H = 0.8, M = 3, K = 3

Displayed in the image are nine points that correspond to three messages encrypted using three distinct keys. Consequently, each horizontal line on the graph signifies all the encryptions for a specific message under various keys. As for the variance in color, consider the following alternative set of parameters:

n = 6, H = 0.8, M = 28, K = 3

If we increase the plaintext length, the number of meaningful messages also increases to 28, resulting in a total of 28 x 3 = 84 encryptions, represented by red and blue points in this particular case. Can you discern the pattern that explains this phenomenon? It may be challenging to identify, but the explanation lies in comprehending the significance of vertical lines in the visual representation. Points that lie on the same horizontal line denote distinct encryptions for the same message, whereas points that are positioned on the same vertical line signify different messages encrypted using the same key. As previously observed, this is precisely the situation where an attacker cannot deduce the secret by attempting all possible keys in reverse, as it is impossible to distinguish the original message among the resulting messages.

Ciphertexts represented by blue points have more than one key that can decrypt them into a meaningful message. Alternatively, blue points signify ciphertexts that possess one or more spurious keys.

sn > 0 ⇒ blue point

sn = 0 ⇒ red point

We can now visualize the properties of information-theoretic security that we mentioned earlier.

sn increases with the size of the key space, |K|

Fixed n, H, increasing values of K

In terms of visualization, the number of red dots proportionally increases.

sn decreases with language redundancy, RL

Fixed K, H, increasing values of n

In terms of visualization, the number of red dots proportionally increases.

Fixed n, K, decreasing values of H (increasing values of R)

Visualizing the categories

In addition to these patterns, we also discussed three general categories that cryptosystems fall into:

H(K | C) = H(K) — Perfect secrecy

n = 8, H = 0.55, K = 256

In terms of visualization, the number of blue dots per column is equivalent to the number of horizontal lines. This indicates that the adversary cannot extract any information from the ciphertext. It is noteworthy that 2^8 = 256, which corresponds to the value of K.

H(K | C) < H(K) — Information-theoretic security

n = 9, H = 0.55, K = 106

In terms of visualization, only blue dots are present. Each ciphertext is partially secured, implying that the attacker lacks sufficient information to disclose the secret definitively.

H(K | C) = 0 — Computational security

n = 13, H = 0.53, K = 29

In terms of visualization, there are red dots indicating ciphertexts that do not have information-theoretic protection and rely on computational security for their confidentiality.

Try it yourself.

This post discusses the main concepts presented in Claude Shannon’s Communication Theory of Secrecy Systems published in 1949. Additionally, we have created a toy model to help visualize the security properties of cryptosystems and how they change with the primary parameters. If you’re interested, you can experiment with the model here. If you’re a teacher and find it useful, please inform us!

The post A Toy Model of Information – Theoretic Security appeared first on Sequent.

Anonymity, Pseudonymity and E-participation

Serhii Bohynia — Wed, 29 Mar 2023 10:04:45 +0000

In this article, we will examine two papers related to the topic of anonymity in e-participation: Ruesch & Märker 2012 – “Making the Case for Anonymity in E-Participation” and Moore 2016 – “Anonymity, Pseudonymity and Deliberation: Why Not Everything Should be Connected.” Our focus is on the concept that there may be an optimal solution in the anonymity spectrum, which strikes a balance between conflicting properties at both ends.

Blog

Anonymity, Pseudonymity and E-participation

Blog, Research

Add a header to begin generating the table of contents

Advocating for Anonymity in E-Participation

We will examine the points raised in the first paper, which presents an analysis of the participatory budget of the city of Gütersloh in Germany. Although the title may suggest a stance in support of anonymity, it is important to note that the concept of anonymity is not absolute and exists on a spectrum. This spectrum is where the trade-offs between opposing arguments take place. The discussion is relevant to various online platforms such as forums, social networks, and the web in general, and therefore, we will first review general points.

General arguments

The self-control argument

There is substantial evidence supporting the argument that anonymous communication often leads to more uncivil discourse, while a real name policy can promote more civilized communication. The ability to be identified by others appears to foster self-restraint, reduce personal attacks, and help establish “communities of trust.”

The legal argument

Advocates of the real name policy emphasize the significance of having easily identifiable profiles to ensure legal accountability for the actions and language used by internet users.

The online=offline argument

If we are expected to be accountable using our real names in our offline lives, why should we not have the same expectation in our online lives?

Conversely

The open participation argument

Requiring users to disclose their real name could lead to the exclusion of many individuals from participating in forums or social networks, particularly in authoritarian regimes where those critical of the government may face repercussions.

The freedom argument

Users are more likely to express themselves freely and without being influenced by groupthink when they are not required to disclose their real identity.

The privacy argument

Users should have the right to choose whether to make certain political or other opinions publicly accessible, especially considering that information once published on the internet can be almost impossible to control.

Arguments specific to E-participation

Many of the points discussed so far are likely familiar as they relate to observations made in the previous post. However, the focus has mainly been on social networks and unmoderated online forums, leaving the area of e-participation relatively unexplored in regards to anonymity and real name policy. This paper aims to fill that gap by explicitly connecting the “anonymity debate” to e-participation, presenting both pros and cons as rationale and objections, respectively.

Rationale 1: Requiring a real name policy and personal data can ensure that only eligible citizens participate, thereby improving representativeness and, in turn, legitimacy.

Rationale 2: Requiring users to disclose their real name and personal data ensures that the quality of dialogue is improved by preventing offensive comments from anonymous users.

Rationale 3: The following objections challenge the points made in favor of real name policy and the request for personal data in ensuring transparent communication and strengthening democracy:

Objection 1: The focus on real name policy and request for personal data can detract from discussions centered on issues, leading to a biased perception of messages that degrades the quality of discourse.

Objection 2: Real name policy and request for personal data infringe upon individuals’ privacy rights.

Objection 3: Requiring a real name policy and personal data can lead to time-consuming and costly administrative issues.

Objection 4: Real name policy and request for personal data can lead to negative media attention and public perception due to legal, administrative, and usability problems they cause.

Objection 5: Requiring real names and personal data may create usability issues that discourage people from participating, ultimately leading to a decrease in overall participation.

The arguments put forth regarding online discussion and the internet at large share a considerable amount of common ground with those presented in the case of e-participation. Rationale 2 and Objection 1 align with the general arguments for self-control and quality, while Objection 2 corresponds with the broader arguments for open participation and freedom.

Preserving Integrity through Pseudonymity

Introducing Integrity Preserving Pseudonymity as a Compromise Solution:

The authors of the paper argue that, based on the Gütersloh experience, the objections to real name policy outweigh the rationales. However, as we mentioned earlier, anonymity is not a black and white issue and there are various compromise solutions between complete anonymity and real name policy. These range from no registration at all to registration with verified personal data.

One potential solution that could be considered a midpoint is Integrity Preserving Pseudonymity. With this approach, citizens are required to validate their real identities to participate in the platform, but their identities remain private and cannot be linked to their pseudonyms beyond the eligibility requirement.

This compromise solution allows citizens to maintain a degree of identity by linking their contributions to their pseudonyms, but still ensures their privacy with respect to both the general public and institutional authorities managing the participation process. This strikes a balance between anonymity and real name policy, where identity is stronger than complete anonymity but weaker than real identity.

Integrity preserving pseudonymity can be established using anonymous credentials, a cryptographic technique introduced by David Chaum (CHA 85). Revisiting the pros and cons of this type of pseudonymity, we can analyze whether the Rationales and Objections support or challenge the use of pseudonymity, as well as the two extremes of pure anonymity and real names. To simplify, we have abbreviated the arguments and merged Objection 4 with Objection 3. The following table summarizes the analysis.

The cells in the table are marked with a check (√) or an X depending on whether the argument supports or questions the use of pseudonymity. Cases where the argument has both positive and negative aspects with respect to the policy are marked with both symbols. Here is a summary of the arguments for pseudonymity.

Legitimacy, integrity

Integrity preserving pseudonymity guarantees that only eligible citizens can participate while maintaining integrity.

Civility

Pseudonymity has characteristics of both real name policy and anonymity. On one hand, since participants are not fully identifiable, there is some possibility for uncivil behavior, which may pose a challenge for accountability. However, on the other hand, pseudonymity does offer a degree of identity through linking contributions to a particular citizen, allowing for a level of accountability. While this level of accountability is not as strong as that offered by real names, it is greater than that provided by pure anonymity.

Communication transparency

According to the definition in the paper, the argument against pseudonymity based on the fact that citizens do not know the real person they are communicating with is considered negative. However, it is possible to make points similar to those made for civility in this context.

Issue-centric debate

This argument is equivocal for the same reasons as described for Civility. The presence of some degree of identity may divert from a purely issue-focused discussion, similar to what happens with pure anonymity.

Privacy, inclusion, freedom

Integrity preserving pseudonymity, by definition, protects citizens’ real identities, which in turn promotes inclusion and freedom.

Administrative complexity

Implementing pseudonymity involves citizen authentication using their real name and other personal information, resulting in similar complexity issues to those of a pure real name policy. Furthermore, pseudonymity requires a meticulous implementation with proper cryptography, leading to administrative complexity and associated costs.

Usability and participation

This argument presents a mixed evaluation for pseudonymity. On one hand, the real name authentication required for pseudonymity may result in complexity issues similar to those for a pure real name policy, decreasing usability and participation. On the other hand, pseudonymity offers some advantages for increasing participation, while still protecting citizens’ real identity, which aligns with the Privacy-inclusion-freedom argument.

The overall evaluation of a pseudonymity policy should consider the relative importance of each argument, rather than simply counting the pros and cons. Pseudonymity can function as an optimal balance between maintaining important properties of pure anonymity and ameliorating its drawbacks. However, the level of identity present in pseudonymity does pose a greater threat to Privacy-integrity-freedom than pure anonymity if inference attacks are conducted on pseudonyms’ linkable contributions. The paper suggests that negative effects of anonymity can be accounted for by the use of pseudonyms and moderation, and that real name policy should be avoided in e-participation projects.

Summary

In Ruesch & Märker’s 2012 paper, we examined arguments both for and against anonymity in general and specifically in the context of e-participation. We noted that anonymity exists on a spectrum and that integrity preserving pseudonymity falls somewhere in between complete anonymity and full identification. We then assessed pseudonymity based on the arguments presented and suggested that, depending on the importance of each argument, it could be an effective compromise that balances conflicting requirements in e-participation systems. [36]

References

(Chaum 85) — Chaum, David (October 1985). “Security without identification: transaction systems to make big brother obsolete”.

(Ruesch & Märker 2012) — Making the Case for Anonymity in E-Participation

[20] De Cindio, Fiorella. 2012. “Guidelines for Designing Deliberative Digital Habitats: Learning from E-Participation for Open Data Initiatives.” The Journal of Community Informatics 8 (2).

[21] Fredheim, Rolf, Alfred Moore, and John Naughton. n.d. “Anonymity and Online Commenting: An Empirical Study.” SSRN Electronic Journal. doi:10.2139/ssrn.2591299.

[22] Cho, Daegon, and Alessandro Acquisti. 2013. “The More Social Cues, The Less Trolling? An Empirical Study of Online Commenting Behavior.”

[23] Diakopoulos, Nicholas, and Mor Naaman. 2011. “Towards Quality Discourse in Online News Comments.” In Proceedings of the ACM 2011 Conference on Computer Supported Cooperative Work — CSCW ‘11. doi:10.1145/1958824.1958844.

[25] Fredheim, Rolf, Alfred Moore, and John Naughton. n.d. “Anonymity and Online Commenting: An Empirical Study.” SSRN Electronic Journal. doi:10.2139/ssrn.2591299.

[26] Davies, Todd. 2009. Online Deliberation: Design, Research, and Practice. Stanford Univ Center for the Study.

[29] Connolly, Terry, Leonard M. Jessup, and Joseph S. Valacich. 1990. “Effects of Anonymity and Evaluative Tone on Idea Generation in Computer-Mediated Groups.” Management Science 36 (6): 689—703.

[30] Flanagin, A. J., V. Tiyaamornwong, J. O’Connor, and D. R. Seibold. 2002. “Computer-Mediated Group Work: The Interaction of Sex and Anonymity.” Communication Research 29 (1): 66—93.

The post Anonymity, Pseudonymity and E-participation appeared first on Sequent.

A bag of Dev Container Tricks

Serhii Bohynia — Fri, 03 Mar 2023 11:03:15 +0000

Nowadays, threre are a lot of tools, libraries, IDEs & plugins that are supposed to make the life of developers easier. But this also adds complexity. Moreover, it may make each developer’s development environment a bit different, depending on how the developer configured these tools.

Blog

A bag of Dev Container Tricks

Blog, Technology

Add a header to begin generating the table of contents

Dev Containers are yet another one of those tools, but they’re one of the most promising projects to solve this issue. Rather than configuring your local environment and fighting against your local machine configuration and needs, you can crowdsource them.

With Dev Containers, any developer can improve the configuration of their development environment. The whole development environment is code: programmable, reproducible, and outsourceable.

Drifting hidden state

Traditionally, you have a long-term personal investment in your development environment. Since it’s only for you and you configured it manually, you don’t really want to touch it or invest time on it – it’d be time wasted! As project and tool complexity has increased, it has only gotten worse.

After some time, you update your Operating System. A new version of Rust is now required for this project and you have to install it. VS Code tells you that there’s a new release, just restart it to apply. The project you are developing now requires newer PostgreSQL installation. You keep being forced to adapt locally to all these changes to maintain a working development environment. And you spend as little as possible on this adaptation, since it’s time wasted.

Sometimes one of these changes starts giving you headaches. You upgraded PostgreSQL for project A, but then Project B stopped working. Or you upgraded your OS and a library is not found. You get the idea.

You end up having an ever-changing, undocumented, unreproducible hidden state. You fear the day in which your computer fails and you will have to set up all this again from zero. With no extra benefit, having to spend maybe a whole day just to get things to a state you already had.

Solve all the above

Dev Containers is not the only tool that tries to solve the hidden state problem. Nix or virtualenv also try to ameliorate it. But it’s a promising approach because it’s quite comprehensive. More than it looks at first-glance.

However, like any new technology, Dev Containers have their own peculiarities. What follows is a bag of tricks and tips of our own, in no particular order:

Trick #1: Remote containers

Dev Containers run the software in a container – you already knew that. This can consume some more resources (RAM and CPU) and make compilation and other processes slower than just running all those natively in your PC.

The above is true only if you don’t take advantage of what containers allow. For example, maybe you have a slim or old laptop with little resources, but you have a badass server at home where you can run the containers. You can easily run the docker containers remotely in that server. Suddenly, your computer is a simple thin client with little need for extra resources. You can compile, rebuild, and launch services within VS Code and your laptop’s CPU and RAM usage won’t suffer.

Trick #2: Github Codespaces

Trick #1 above is fine but requires:

Having a secondary machine with spare resources.
Configuring this machine to be a remote docker host.

If you don’t have (1) or if you are just lazy to do (2) like I am, then I’ve got a better alternative for you: Github Codespaces. It allows you to do pretty much the same, except the containers are going to be run automatically by Github in Microsoft Azure cloud. For personal accounts, this includes currently 60 free hours per month, which is not too shabby.

Trick #3: Prebuilds for Github Codespaces

You can configure the Dev Container to execute a command with onCreateCommand when the container is created, for example configuring and building your source code and fetching all the dependencies. However, building the docker images and performing from scratch all those steps each time you spin a new Dev container environment can take a while, sometimes even more than 20 minutes or more. That is NOT good. You don’t want to wait half an hour just to start coding!

Github has you covered here. prebuilds to the rescue. Prebuilds help to speed up the creation of new codespaces by performing these expenses steps and generating a ready-to-use Dev container image when you push changes to your repository. Bottom line is: instead of 30 minutes to spin a new codespace, now it’s maybe a minute and your code is freshly already compiled and ready to go. Feels like magic in comparison.

Trick #4: nix-devcontainer

Nix makes builds reproducible and thus safer, so we wanted to use it as a package manager. Unfortunately, some vscode extensions do not integrate well with Nix. To workaround this issue, we use xtruder/nix-devcontainer which applies a hack that fixes it by preloading a given set of extensions, for example arrterian.nix-env-selector, before any other.

Without this, you would otherwise have to for example install rust toolchain twice: one with nix for your flake, and another via apt-get for VS Code to work properly. Not anymore!

Trick #5: Leveraging Cachix

cachix is the most-well known online service cache for Nix. We use it in Github Actions to speed them up and we use it also in the prebuilds mentioned earlier, so that the prebuild process happens faster.

Within the flake.nix of your package, you can use nixConfig to setup access to your public nix cache for any user to take advantage of, just like we do here:

				
					{
  # ...
  nixConfig = {
    extra-substituters = [ "https://sequentech.cachix.org/" ];
    extra-trusted-public-keys = [ "sequentech.cachix.org-1:mmoak2RFNZkQjHHpKn/NbsBrznWqvq8COKqaVOI6ahM=" ];
  };
}

Now when a user runs nix develop, it will launch the flake’s default devShell but instead of building everything from scratch, it will have read access to the same nix cache as everyone else.

However, it will be first asked to trust this third-party cache. And this is a nice security feature, but might be annoying for example when running commands within the nix develop environment in the prebuild setup script. To fix this, you can either:

a) Run any Nix command with an extra --accept-flake-config parameter.

b) Configure your Dockerfile to do that by default as we do in Dockerfile and nix.conf.

Another way to leverage Cachix in Rust projects is to use crane. The beauty of crane is that it allows you to build your rust dependencies just once and then lint, build, and test changes to your project without slowing down. This is something more related to Github Actions, but you might also take advantage of this in the prebuild process within the Dev Container.

Trick #6: Leverage the power of vscode

You can use all kinds of VS Code stuff within Dev Containers, and everyone will benefit from the time each other spends in having a top-notch development environment configuration. It’s multiplicative. Here are some examples:

You can configure the editor settings in .vscode/settings.json. If your project is using 80 character lines, maybe you want to add a ruler with "editor.rulers": [80],. This makes the policy clear for the whole development team.
You can setup preinstalled vscode extensions in .devcontainer/devcontainer.json.
You can configure your project debugging settings in .vscode/launch.json.
You can configure some typical tasks like running the unit tests, running the server backend or applying the linter with .vscode/tasks.json.

As we said earlier: anyone can improve the development environment configuration and everyone benefits.

Trick #7: Going multi-repo

Google famously uses a single monorepo architecture. However, in open source typically you don’t. Typically you have multiple repositories to make it easy to let other people collaborate and reuse specific projects. Sequent Voting Platform is open source not only by license but we also buy the philosophy of collaboration, so we are multi-repo.

However, it can be challenging to manage multiple repositories during development. For example, recently I was developing the bulletin-board using Dev Containers and I needed, for this feature I was coding, to also apply some minor code changes to one of the dependencies of the bulletin-board, strand.

Should I spin two different codespaces for that? What if I need to touch code in multiple dependencies? Well, don’t worry too much because yet again, Dev Containers and codespaces have a solution for that.

First, you can configure the devcontainer.json to give git commit permissions to other repositories of the same organizations like we do here. More details in the documentation.

Second, you can modify your onCreateCommand script to download this and any other dependency locally (just do a git clone).

Third, use this local dependency. How to do this will depend on your toolchain. If you are using Rust, my advice is: don’t touch Cargo.toml. Yes, one quick and dirty option is to change your dependency from something like, maybe:

				
					strand = { git = "https://github.com/sequentech/strand", features= ["rayon"] }

to:

				
					strand = { path="./strand", features=["rayon"] }

But then you might end up committing that change in Cargo.toml.and that just isn’t good .

Instead, you should create a new file to override dependencies called .cargo/config.toml, and add there something like:

				
					[patch.'https://github.com/sequentech/strand']
strand = { path = "strand", features= ["rayon"] }

Additionally, add the .cargo/config.toml to .gitignore to ensure you don’t inadvertently commit this file.

Trick #8: Use multiple containers with docker compose

Maybe you are developing a backend service and you need to use a PostgreSQL database to run it. Or maybe you want to be able to run both the frontend and the backend within your development environment. Or.. you get the point.

You can orchestrate the launch of multiple containers with docker compose. Because why not, it’s more flexible to always configure your devcontainer.json using docker compose.

Trick #9: Multiple Dev Container configurations

Contemplate these cases:

There are times you need to work with a local copy of dependencies, there are others you don’t.
There are some times where you broke your prebuilds and you want to launch a new Dev Container with no setup script.
Maybe sometimes you want to develop with an environment using PostgreSQL as a database backend and others with MariaDB.
Or maybe you actually have multiple projects within a single repository and you want to be able to have a ready-to-go Dev container for each of them (Hello there monorepo people!).

All this can be solved using multiple Dev Container configurations. You can have multiple, ready-to-go devcontainer.json files inside the .devcontainer directory, using the pattern .devcontainer/{name}/devcontainer.json. And Codespaces also supports this feature natively.

Remember these tricks are composable. For example, in this case you can configure prebuilds for each Dev Container configuration.

Trick #10: Custom codespaces

In Github Codespaces you can use the Advance Create feature to configure in more detail your new codespace: choose the specific branch, the number of cores or amount of RAM of the container, the Dev Container file, and actually it has a nice interface to just modify manually the devcontainer.json before launching. This can be helpful in disaster recovery scenarios, for example in broken configurations you can edit the onCreateCommand or anything else.

Trick #11: Garbage collection

Dev containers are typically launched with a specific disk size. Sometimes this turns out not to be enough. Now imagine you have uncommitted/unpushed changes in the container. There are multiple things you can do:

If the problem is that Nix is using too much space, try running nix-collect-garbage.
You can use the Github Codespaces UI to export changes to a branch.

Oh and now that we are talking about garbage collection: you can also review and manage all the codespaces you personally have in github.com/codespaces. When working with multiple repository, with multiple features or branches, you might forget about some codespaces.

Codespaces typically auto-stop after idling for 30 minutes – and of course this is configurable. But they are still wasting/spending disk space. So go to github.com/codespaces and delete all your unneeded codespaces.

Trick #12: Codespaces vscode plugin

So you can go to your repo in github.com, click on the big green button (Code) and launch a new codespace right there and it will open the codespace in vscode running within the web browser in a new tab.

But it doesn’t stop there. You can perhaps close that tab, and then click again in that green button, see there listed your just-created codespace, click on the ... button -> Open in.. -> Open in Visual Studio Code. And if your local vscode installation has the Codespaces extension it will just open in a new window of your vscode.

You can even forget altogether about the web browser and do the whole thing from within vscode. With Cmd + Shift + P search for Codespaces and from there you can: connect to a codespace, stop a codespace, rebuild it, create a new one from a specific repository.. you name it.

Wrapping up

There are other avenues to explore in the future. For example, denvenv.sh also supports integration with Dev Containers and they surely also integrates well with cachix since it comes from the same developer.

Another trick we have not explored yet is to use Dev Container Features to package (quote) “self-contained, shareable units of installation code and development container configuration”.

We’ll continue our road to making development easier and keep you updated.

The post A bag of Dev Container Tricks appeared first on Sequent.

Homomorphic vs Mixnet Based E-voting

Serhii Bohynia — Mon, 20 Feb 2023 07:44:38 +0000

Although proposals have been made using other techniques, most common modern approaches to constructing secure voting systems can be divided into two categories: those based on homomorphic tallying (shorthand “homomorphic systems”) and those based on verifiable mixnets (shortand “mixnet systems”). Most systems, both prototypes in academia as well as production systems in industry, use one (or both) of these technologies to achieve the necessary properties for what is termed secure e-voting, and the related gold standard end-to-end verifiable voting.

Blog

Homomorphic vs Mixnet Based E-voting

Blog, Research

Add a header to begin generating the table of contents

In this post we briefly describe the two approaches and then offer a qualitative pros & cons comparison of the two for aspects we have found significant in our experience evaluating and operating such systems. Given that Sequent’s voting system uses a mixnet as its core, it is unsurprising that our conclusion following the below comparisons leans in favour of that choice when building a secure voting system. However, at Sequent we’re open to the possibility of adding a homomorphic backend to our platform if careful analysis suggests it is desirable for particular use cases that may arise.

Homomorphic tallying

Voting systems based on homomorphic tallying exploit the homomorphic property of the underlying encryption to compute tallies. This homomorphic property makes it possible to add encrypted numbers together without decrypting them. The beauty of applying this technique to voting lies in the fact that when computing an election result we do not need to decrypt individual votes, only their sum, so that the secrecy of an individual’s ballot is preserved.

Unfortunately some technicalities have to be solved. We need a way to encode voter selections in a way that is amenable to this type of summing. This usually amounts to constructing vectors of ciphertexts for which a 1 represents a marked option on the ballot while a 0 represents an unmarked one, and then summing these vectors component-wise. In addition, because we only decrypt sums we also need a way to ensure that these encryptions represent valid choices. Not only because ballots could be nonsensical, but they could also be constructed maliciously to grant a voter more power than they ought to have. Preventing such cases is accomplished using zero knowledge proofs: using that technique we still don’t learn the contents of individual ballots but we are assured that they are valid.

You can learn more about the technical details of homomorphic tallying from any of the existing proposals featuring it in the literature, a prominent example is ElectionGuard.

Verifiable mixnets

Unlike homomorphic tallying, systems based on verifiable mixnets do decrypt individual ballots, but they do this after a process of anonymization which breaks the link between an encrypted ballot and the voter that cast it. The anonymization process amounts to a shuffling of a set of ballots such that the output set cannot be correlated with the input. The central problem that a verifiable mixnet solves is that of performing this shuffle while still ensuring that the output of that process corresponds to what went in, in other words, no manipulation took place. This is where, as above, zero knowledge proofs enter the picture, ensuring that the shuffling is correct while revealing no other information.

(A mixnet with three nodes, taken from here)

Verifiable mixnets come in different flavours, one example (we use at Sequent) is that of re-encryption mixnets. These implement the shuffle by permuting and re-encrypting the input ciphertexts such that the result is a shuffled set of ciphertexts that are equivalent but cannot be correlated with the input. Of course, whoever performs this shuffle does know the correspondence, but that’s where the “net” part of mixnet comes in. If this process is repeated by several independent parties, none of them will be able to trace the path of any ciphertext through the mix network: this will only be possible if all the independent parties pool their information together. So in effect, a mixnet implements a distribution of trust for the secrecy of the ballot, a recurring theme for secure voting systems.

You can learn more about all the technical details that we use at Sequent in these papers, and of course directly looking at our source code repository.

Comparison

Given this short description of the two techniques let’s take a look at some pros and cons of each for e-voting. We have divided the comparison into sections that are significant in our experience, in alphabetical order.

Generality

By generality we mean the degree to which the underlying cryptographic protocol can support a wide range of election and ballot types. Starting from the simplest election type, one which poses a yes/no question to voters, election and ballot types can increase in complexity up to schemes involving, for example, choosing one or more out of several choices, ordering of choices, scoring choices numerically, or even write-ins where voters can outright fill in a previously unspecified choice.

Generality is probably the axis along which homomorphic vs mixnet based voting systems differ most. As we mentioned before, a homomorphic tally system needs to convert voter’s ballots into suitable ciphertexts that can be summed exploiting the scheme’s homomorphic property. Unfortunately, beyond the case of choosing n-out-of-k options, this rules out the more complex examples we mentioned. Mixnets on the other hand can handle arbitrary ballot types, provided the ciphertext is sufficiently large to capture the ballot information. This makes generality a strong advantage of mixnet systems over homomorphic ones.

Implementation complexity

This category refers to the complexity of the software that makes up the voting systems. Absent other considerations, a higher implementation complexity is a negative factor in our comparison. One immediate reason is the higher difficulty in developing and maintaining the software that makes up the system. More importantly, a more complex implementation is more vulnerable to implementation errors and is harder to secure against both random errors and adversarial attacks.

In terms of total implementation complexity it is probably fair to say that a homomorphic system is less complex and wins out in this category. But this result leaves out important details as to where the complexity lies. Whereas mixnet systems pay a high complexity cost for the development of the shuffling and its proofs, homomorphic systems pay most of their complexity cost in ensuring that cast ballots are correctly constructed. This difference is a reflection of a key difference between the two. Homomorphic systems do not decrypt individual ballots and rely on complex proofs to certify that said ballots are valid. Mixnet systems however do decrypt after anonymization, so it is trivial in that case to remove invalid or maliciously constructed ballots.

The consequence of this difference is that homomorphic systems pay a large fraction of their complexity cost on the client where complex proofs must be constructed, and less so on the backend where the tally is more straightforward. Mixnets have the opposite complexity layout, the shuffle and tallying software is sophisticated, whereas the client is relatively simple. It could be argued that complexity on the client side is more problematic, since it is deployed in an uncontrolled environment, the user’s device, and is subject to greater degree of heterogeneity and uncertainty. Conversely, the backend runs in a controlled environment, the systems that specialised entities must run as trustees. In spite of this, we maintain that homomorphic systems come out ahead with respect to implementation complexity.

Performance

The discussion here draws parallels with the previous section, but replacing implementation complexity with computational complexity. Specifically, a homomorphic system requires more computation on the client side and less so on the backend. This occurs because these systems typically encrypt each possible selection with a ciphertext, resulting in vectors of ciphertexts that grow with the number of options presented to the voter. On top of this, zero knowledge proofs must be constructed for each of these encryptions. Both the encryption and the zero knowledge proofs add computational cost, a computation that takes place in the voter’s client which is limited in performance. On the other hand, once the ballots have reached the backend the necessary computation to verify them and perform the homomorphic sum is reduced, relative to the hardware characteristics available in a server environment..

Mixnet systems have the opposite layout. Ballot selections can usually be encoded into a single ciphertext, and proofs of validity are not essential as ciphertexts are decrypted after anonymization. However, the process of anonymization, the shuffle, is computationally intensive and grows in complexity the higher the degree of trust distribution is required. Depending on the techniques used, the size of the electorate and the hardware involved a tally can take up to hours in the worst cases.

Both homomorphic and mixnet based systems may encounter situations which make it a suboptimal choice. But while it is difficult to remedy cases in which client devices cannot be expected to compute large numbers of ciphertexts and proofs, it is usually easier to “throw hardware at the problem” on the backend. For this reason mixnets are more robust to demanding performance scenarios. However, when they can be applied, homomorphic systems show significantly better performance than mixnet systems in general.

Privacy

There are different degrees to which a voting system can be said to achieve privacy. The most common and basic requirement is ballot secrecy: the voting system does not reveal who voted for what. There are stronger notions of privacy such as receipt-freeness, where the voter cannot prove how they voted, and coercion resistance where the voter is able to cast their chosen vote even under the influence of a coercer.

Homomorphic and mixnet based e-voting systems have been the subject of academic research for decades in an attempt to satisfy these requirements. While many proposals exist that achieve ballot secrecy, receipt-freeness and coercion resistance are still an open problem. Our comparison with respect to privacy is then limited to ballot secrecy.

If constructed correctly (including choices for security parameters), and modulo implementation complexity aspects, both types of systems offer comparable ballot secrecy using cryptography that relies on well known hardness assumptions. In fact, in prominent instances of protocols of both kinds there is overlap in the cryptographic techniques with identical security properties, as is the case for example when using the ElGamal cryptosystem.

There are some considerations that escape a binary definition of ballot secrecy. One could argue that the tally counts are a form of leakage since they reveal more information than strictly the final result itself, a concern addressed by research into tally-hiding schemes. But this is true for both types of systems; homomorphic e-voting systems are not fully homomorphic, and are unable to perform arbitrary computations in ciphertext space to yield leak free results. In summary, we consider homomorphic and mixnet systems to be comparable with respect to privacy.

Verifiability

The gold standard for secure voting systems is end-to-end verifiability. A system is end-to-end verifiable if it is possible to certify that each of the key operations that make up an election (ballot casting, ballot recording and ballot counting) have been executed correctly. The question then becomes about whether homomorphic and mixnet systems can satisfy the requirements that make a system end-to-end verifiable.

Again, homomorphic and mixnet based e-voting systems have been the subject of academic research to satisfy these requirements. Within the category of end-to-end verifiability, there exist different proposals as to how each step of the verification takes place. One notable step is cast-as-intended verification, for which adequate usability is still an open problem. But whatever mechanisms are chosen to perform these verifications, they are generally equally applicable to both homomorphic and mixnet systems.

We can say that, if constructed correctly, both types of systems achieve comparable levels of verifiability; there are many examples of both types in the academic literature on end-to-end verifiable systems. Helios in particular is a system that has been proposed in both homomorphic and mixnet variants. In summary, we consider homomorphic and mixnet based systems to be comparable with respect to verifiability.

Conclusion

One would think that the conclusion of our qualitative comparison between homomorphic and mixnet based systems would favour the former, given that it edges out its mixnet counterpart in more of the categories above. However, this advantage only manifests in the concrete cases where homomorphic systems can be applied at all. In contrast, mixnets can handle a much wider range of scenarios, albeit at a higher complexity cost. If one requires a system for a particular use case which does not rule out homomorphic based systems, they are better. But if one wants a future proof system that can be relied upon in general, mixnets are a better choice.

The post Homomorphic vs Mixnet Based E-voting appeared first on Sequent.

Bringing Sequent’s End-To-End Verifiable Voting Solution to the German Market

Serhii Bohynia — Tue, 14 Feb 2023 04:10:38 +0000

Based in Lueneburg, Germany, Electric Paper Informations Systeme (EPI) is a company that provides impactful solutions for the digitalization of the workplace and has been working in the field of tension between “people, paper and processes”. For over 20 years, they have contributed to the efficient conduct of internal elections across departmental and organizational boundaries. EPI has partnered with universities, enterprises, trade unions and chambers of commerce to offer both paper-based and online voting options in elections, ensuring reliable, customizable and scalable end-to-end voting solutions for its customers.

Blog

Bringing Sequent’s End-To-End Verifiable Voting Solution to the German Market

Blog, Case Studies

Add a header to begin generating the table of contents

Challenges

Complicated Electoral Processes

Every year, EPI conducts multiple elections, many of them for both national and highly complex organizations with special ballot requirements that can complicate the election process. One example is the University of Muenster who commissioned EPI to create 99 different ballot styles that included relevant student candidates based on their majors. The complexities of such electoral processes done on paper, increases the possibility of human mistake. In addition, paper-ballot designing, printing, distributing, and counting in this case can be extremely costly and challenging from an operational perspective.

Hybrid Elections – In-Person and Remote Voting

With the COVID-19 pandemic and growing demand from EPI’s clients to make voting more convenient and accessible to voters, EPI needed a solution that would work seamlessly with their election management system (uniWAHL) to provide a fully online or hybrid elections where it was possible to vote both in-person (on paper) and remotely using the voter’s mobile. The solution should also be flexible enough to suit the various requirements of their clients without the need for custom development.

EPI initially thought about developing their own solution for the German market, but developing such a program that adheres to security, accessibility, end-to-end verifiability and regulatory standards comes with a significant amount of capital investment required, development challenges and would dramatically delay the time-to-market.

Security, Regulations and Accessibility

As EPI decided to make the transition to offering its clients the option to vote remotely online (with or without an in-person paper-based voting option) it was now imperative for them to find a solution that allowed them to seamlessly handle online voting with their election management system (uniWAHL) and at the same time, match the same level of security, data-compliance and the Council of Europe Recommendation Standards for e-Voting (e.g. online voting). Furthermore, the solution had to be mobile-friendly, fully responsive and easily accessible to people with disabilities.

How Sequent Helps EPI

EPI selected Sequent’s online voting platform and with the guidance of Sequent’s development team, successfully integrated it with their existing election management software, uniWAHL, to deliver fully online or hybrid elections in a safe, reliable, scalable, and cost-effective way to their clients.

Election configuration and results are imported directly to and from Sequent’s online voting solution (locally branded as EPI’s OWS – Online Voting System) and the entire system is hosted on German Deutsche Telekom servers and is operated on a highly-secure level.

In short, the focus is on providing a combination of paper-based voting, where votes are manually submitted and scanned for tallying, as well as an online solution for remoting voting, EPI along with Sequent’s solution offers an end-to-end voting solution for its clients.

Regulations, Security, and Verifiability

Sequent’s solution has been in development since 2014 in accordance with online voting standards and cybersecurity best practices, including the Council of Europe Recommendation Standards from 2017. Moreover, Sequent is developing its solution as an open-source software, in close collaboration with academic experts and uses battle-tested cryptography to ensure end-to-end verifiability (where voters can individually verify their ballot cast and count them correctly and where auditors can audit the election results) – This is why Sequent’s unique approach was a natural choice for EPI.

Easier Management of Complex Electoral Processes

By leveraging Sequent’s comprehensive API interface, EPI was able to easily design in their election management system multiple, user-friendly ballot styles and seamlessly create a digital copy on Sequent’s platform. In the case of hybrid elections, a twin copy of the paper ballot will be created on the Sequent platform to ensure a unified voter experience. Cast ballots will later be consolidated back into EPI’s system to ensure a single source of record.

Accessibility

Sequent’s online voting platform is a web-based, mobile-friendly, and fully responsive application. This means voters are not obligated to download any app in advance and can use the most current (as well as older models) mobile devices or a PC to cast their ballot. Sequent is also fully compliant with WCAG 2.1 AA standards for people with disabilities.

Cost-Effective Solution

Even though organizations that are transforming to hybrid elections may experience increased costs through the transition period as voters are presented with the option to vote remotely online and/or arrive in-person to vote on paper, it provides the option to gradually narrow down the in-person operations and move online entirely, thus saving costs in the long run. Organizations that are able to move to online voting immediately enjoy the benefits of lower-cost elections right from the start.

Deploying online elections also allows EPI to rely less on expensive human operations to print, deliver and count complex paper ballots in their client elections, in turn, allowing them to onboard more new clients with minimal operations and support.

In Conclusion

With 32 elections and over 250K voters served in 2022 only, Sequent continues to work closely with EPI in delivering dependable, safe, and affordable hybrid or fully online elections that meet the expectations of their clients. “Integrating Sequent’s solution with our existing uniWAHL voting products was a good choice. It empowers our customers to run hybrid or fully online elections while dramatically reducing their overall election cost and logistics.” – Lars Riemenschneider, CEO – Electric Paper Wahlsysteme, Germany.

The post Bringing Sequent’s End-To-End Verifiable Voting Solution to the German Market appeared first on Sequent.