blog Archives - 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.

Calling Go Code From Rust: A Google Trillian Story

Serhii Bohynia — Sun, 22 Jan 2023 05:32:34 +0000

Although we have not officially announced any specific plan, it’s not a secret that at Sequent we’re developing our 2nd generation secure voting platform, because we work out there in the open.

Blog

Calling Go Code From Rust: A Google Trillian Story

Blog, Technology

Add a header to begin generating the table of contents

The bulletin board and its requirements

Although we have not officially announced any specific plan, it’s not a secret that at Sequent we’re developing our 2nd generation secure voting platform, because we work out there in the open.

One of the most critical pieces of our 2nd-gen platform will be the bulletin board. In voting systems’ jargon, the bulletin board is a broadcast channel with memory that stores relevant election information such as cast votes, public keys and election results.

What follows is a non-exhaustive list of the requirements we have for the bulletin board:

Verifiability: It is tamper-evident append-only log. Added entries cannot be removed or modified, and this should be verifiable by third parties for transparency.
Authenticity: All posts to the bulletin board must be authenticated, in this case with digital signatures.
Performance: It supports adding multi-gigabyte entries. Intermediate steps of the mixnet cryptographic protocol might include millions of votes. That’s gigabytes worth of data.
Performance: scales to +1K votes/second. A must for elections with hundreds of thousands or millions of voters. We want to store votes in the board while people are voting, to increase verifiability.
Storage: Board can be archived/retrieved as files. We want to be able to persist data easily using AWS S3 or similar. A board client should be able to use this bulletin board in read-only mode without having any other backend service running. Anyone should also be able to download easily the board a local copy and work transparently from it.
Compliance: Supports filtering entry data for compliance reasons like the right to be forgotten in GDPR without compromising other requirements, in particular the verifiability of the tamper-evident log.
Language: Rust development – it’s the language we have chosen for our 2nd-gen platform.

This is a hard nut to crack with conflicting requirements. That’s one of the wonderful aspects of voting technology: working in challenging problems.

We could debate what is the right technology to implement a bulletin board. There are different approaches others have tried, ranging from trying to use Ethereum or any other blockchain, using git as a simple and well-known hash-chain or perhaps using a database like PostgreSQL as the backend storage. None of those provide a satisfactory level of compliance with the requirements previously outlined. That might be the topic of some other post.

We settled to use a serverless Google Trillian-based log. Which brings us to..

What is Google Trillian?

Long story short, Trillian is a tamper-evident log. Its github repository description is “A transparent, highly scalable and cryptographically verifiable data store.” Trillian is written in Go Language, and it allows to register entries in a log that other can query, monitor and request inclusion of new entries. It’s transparent and tamper-evident because it stores the log using a Merkle Tree, which is just a tree of hashes of data where the leaves are the entries, and it allows to efficiently add entries, verify entries order and inclusion, and compare an evolving tree of entries and see that two different tree snapshots are consistent, i.e. older entries are still there in the expected location.

Google developed Trillian as a generic implementation of Certificate Transparency (CT). If you are reading this blog post, you are using Certificate Transparency. Your web browser and millions of other web browsers use CT to verify that the digital certificate of any website using https have been logged in a publicly available and verifiable trillian-based log. The idea is that the browser will only accept certificates that everyone knows about because they are publicly logged. CT has 8.4B certificates logged so far. And counting. Cool technology indeed.

As mentioned earlier, Google Trillian is just the generic implementation of CT, allowing to log any kind of entries, not just digital certificates. In our case, we will log election data.

Trillian serverless

We cannot use Google Trillian simply as a service, because it doesn’t comply with our requirements: it’s not performant enough either in the size of entries (doesn’t support multi-gigabyte entries) not in terms of speed (with MySQL it handles ~10-20 new entries per second). Also, the storage backend is typically mysql and to access the data, you need the trillian service running.

We’ll be using trillian serverless instead. Instead of using Trillian as a service, we would be using some of the Trillian library code to create our own log. Trillian Serverless (TS) stores everything as files, and any client can just access the log this way – no need for a running backend server, other than a generic file server like AWS S3 or even Github Pages. Each entry will be stored as a file along with a set of tiles that represents the hash tree (Merkle Tree) of the log. Entries can easily be sized in gigabytes, and well, for small entries it’s performant enough as we will see.

A small note about compliance and the right to be forgotten: if for any reason a specific entry needs to be password-protected or just not publicly available anymore, having a hash tree (Merkle Tree) with entries being the leaves of that tree and represented as files allows for checking consistency of the log, even inclusion of a specific entry, even when a specific entry data file is not publicly available anymore. This feature is not implemented yet though.

C FFI, the gold standard in interoperability

At this point we know that we are implementing our Bulletin Board using Rust, but we will be calling a library written in Go. Rust has different kind of data structures than Go. Even though both are compiled and feature strong typing, Go uses a Garbage Collector for dynamically allocating and managing the lifetime of objects in the heap, while Rust uses ownership, the type system and the borrow checker instead. Is this even.. possible?

Turns out it is. The reason is both can talk to each other using a common lower denominator: the C Foreign Function Interface (FFI), which is (excerpt from Wikipedia): “A mechanism by which a program written in one programming language can call routines or make use of services written in another.”

What we intend to do is to end up with a compiled binary, which is our bulletin board service implemented in Rust, that will include a statically linked Go library that provides a C-FFI interface. The binary will depend on little more than libc.

For implementation purposes, we will be needing to understand how to translate in and out from and to C FFI both in Rust and Go. The way a function call from Rust to Go will usually happen is:

Rust function: We have some Rust code that needs to call the functionality provided by Go. We call the Rust wrapper function that provides access to that functionality.
Rust Wrapper function: Our Rust wrapper function converts Rust data structures to data structures that can be managed and understood by the C FFI. After conversion, this wrapper will call a C FFI function provided by our static Go library.
Go Wrapper function: Our Go wrapper function provides an interface for that C FFI function, and this Go function receives the call from previous step. The first thing this wrapper function does is converting the input data to data structures managed by Go and easy to work with in Go, and then starts working with this input data.
Go function: Our Go function calls whatever Go functions with the input data (in our case, from Trillian) obtaining some data that needs to be returned, and returns this to the Go wrapper function.
Go Wrapper function: Our Go wrapper code converts these Go output data structures to something that can be returned through the C FFI interface.
Rust Wrapper function: The output data is received by the Rust wrapper code and is converted into Rusty data structures.
Rust function: The Rust wrapper code returns to the initial Rust function that uses this output data and goes on with life.

How to actually do this?

If you need to call Go code from Rust, unfortunately there’s not much documentation out there and what you can find is quite scattered along the tubes. Here is a bunch of references that I found useful:

Since our project includes some other advanced techniques like passing structs from Rust to Go and back, you might also be interested in just taking a look at our bulletin board.

How to actually do this?

This is becoming a bit of a long post, so we will mention a couple of the interesting bits which might not be particularly well documented and I found particularly interesting:

Integrated builds of Go and Rust

One of the most annoying things during this endeavour is the manual work of just building. How do you approach build both? Do you create a distinct package for the Go code? While changing both Go and Rust code, do you always manually first compile the Go code and then build with cargo build?

Our approach was: build Go code automatically, from cargo. You can do this using the build scripts through build.rs.

				
					fn main() {
    // Instruct cargo that if these files change, it needs to
    // rerun this script
    println!("cargo:rerun-if-changed=trillian-board/main.go");
    println!("cargo:rerun-if-changed=trillian-board/go.sum");

    // Build the go static library
    run_command(vec![
        "go", "build", "-buildmode=c-archive",
        "-o", "libtrillian_board.a", "main.go"
    ], cwd="./trillian-board/");

    // Instruct cargo to statically link to the just-build
    // static library `libtrillian_board.a`
    println!("cargo:rustc-link-lib=static=trillian_board");
}

Note that this is just some sample Rust pseudo-code. For the real life nitty-gritty details, take a look at our actual build.rs file in sequentech/bulletin-board repository.

Performantly passing big data arrays from Rust to Go

After looking at the 6 steps of calling Go code from Rust, it’s difficult not to have concerns about performance when having so many intermediate steps just to do a simple function call. The real truth is that obviously performance is not as good as just using Rust code, but on the other hand in some cases it’s not as bad as it looks.

When creating new entries, we need to pass the entry data (remember, potentially gigabytes of information) to the Go code. In our current work-in-progress version of the system, we do all that with heap-allocated Rust array.

Following a suggestion in Stack Overflow, we found a way to convert a Rust Array to a C FFI owned array:

				
					fn vec_to_cffi_array<t>(input: Vec<t>) -> (*mut T, usize) {
    let boxed_slice: Box = input.into_boxed_slice();
    let length = boxed_slice.len();
    let fat_ptr: *mut [T] = Box::into_raw(boxed_slice);
    let slim_ptr: *mut T = fat_ptr as _;
    return (slim_ptr, length);
}</t></t>

Apart from allocating a variable holding the length of the array as part of the returning tuple, there’s no extra memory allocation – we are just dancing with the type system, but in the end we simply convert the Vec into a pointer. The receiver will now be in charge of managing the allocated memory though. More on that later.

BTW we also needed the reverse function (from C FFI Array to rust): also possible with no big memory allocations.

How to use this data array in Go? Well, that turned out to be easy. Just use unsafe.Slice, like we do:

				
					entries := unsafe.Slice(entriesC, numEntries)

This code allows Go access the array as a Slice through the entries variable, indicating to Go that this is memory that the Go Garbage Collector does not need to manage itself. So at this point you need to remember to free the memory to avoid memory leaks. You can do that in Rust side or in Go side. We decided to go the rusty path, using a function like follows:

				
					fn free_vec<t>(ptr: *mut T, len: usize) {
    if ptr.is_null() {
        eprintln!("free_vec() errored: got NULL ptr!");
        ::std::process::abort();
    }
    let entries = unsafe { slice::from_raw_parts_mut(ptr, len) };
    drop(unsafe { Box::from_raw(entries) });
}</t>

The performance we get is pretty decent when adding entries to this trillian-based log. For small entries, we achieve more than a 1,000 separate inserts per second (sequence+integrate in Trillian terminology). That’s about 2 orders of magnitude more than the ordinary Trillian service that uses MySQL. Without any further optimization. Screenshot from our benchmark:

Stay tuned

There are other interesting insights, techniques and technologies we are using in our 2nd-gen platform that we might want to talk about in the future. For example, about how we generate reproducible builds with Nix or about all the Github Actions we have on every push that include from checking license of dependencies to automatic benchmarking. Stay tuned for more to come.

In the meantime, you can play and tinker around with our work-in-progress and yet-to-be-released open source bulletin board right now, because with one click you can launch a fully working development environment (the exact same one we use) by launching it with Github Codespaces. Isn’t that wonderful? It feels like magic.

The post Calling Go Code From Rust: A Google Trillian Story appeared first on Sequent.

A Universal Approach to Election Verification: An Opportunity for Increased Trust in Elections

Serhii Bohynia — Wed, 14 Dec 2022 05:42:11 +0000

A voting system is termed end-to-end verifiable (E2EVV) if it provides procedures to check that all steps of the voting process are executed correctly. These procedures include both human executed as well as automated software checks. Because the verifiability of end-to-end verifiable voting systems is based on mathematical proofs, the corresponding checks take the form of software components that mechanically verify these proofs generated by the system during a voting process.

Blog

A Universal Approach to Election Verification: An Opportunity for Increased Trust in Elections

Blog, Technology

Add a header to begin generating the table of contents

Introduction

Ideally, these verification tools, which we call verifiers, should be written independently of the system they verify, by people not associated with it. This independence, both of software as well as of people, increases the confidence in the verification process, for technical as well as trust reasons.

In practice, providers of E2EVV systems, which range from academic projects to commercial vendors, do not dedicate sufficient resources to ensure that these independent tools and procedures are developed. This is not surprising, because this development is expensive, even more so if done in an independent and principled (with the least amount of assumptions beyond mathematical specifications) way. Moreover, the incentives to dedicate these resources are not in place: there exist no agreed upon precise technical standards that the population at large can use to evaluate to what degree systems are indeed E2EVV. Consequently it is unclear what the return on investment for efforts to meet high standards in this area, including quality verifiers, are.

At the same time, many existing E2EVV systems share a substantial amount of commonality in the mathematical fundamentals at the base of their verifiability. Indeed, one can classify most E2EVV systems into very few classes according to the main cryptographic techniques they employ. The most cited examples are mixnets, homomorphic tallying, and blind signatures.

A Universal Verifier

The combination of these two observations naturally suggests an opportunity to improve the current state of affairs: if most E2EVV systems share substantial underlying technology, it is possible that this commonality could be exploited to achieve a high quality universal verifier compatible with all of them. This universal verifier would be a joint effort from all E2EVV players, in effect being independent of each provider individually. But the benefits of such a project are not limited to improving the state of election verification software.

The work necessary to define and develop a universal verifier for these systems would constitute the first steps towards the definition of precise standards defining and potentially certifying what an E2EVV system is. This is because in order to develop a universal verifier one needs to define verification very precisely (to the point of mechanical execution) and in sufficient generality (to be compatible across all instances of E2EVV). The long term outcome of these first steps would be a robust, rigorous and precise technical standard that would elevate the practices of all participants and instantiations of E2EVV voting. But because there are already benefits in providing a universal verifier compatible with existing systems today, it could be possible to bootstrap a standardisation process without a huge initial investment.

First steps

The first step in the path towards a universal verifier supporting arbitrary E2EVV systems is to identify a small selection (say 2 or 3) of E2EVV systems currently in use and to develop a prototype that targets them. As a proof of concept this would serve to remove uncertainty from some of the fundamental problems a full fledged universal verifier could present, for example:

Whether it is possible to extract sufficient commonality in underlying mathematical constructions to make a universal verifier generally applicable.

Whether it is possible to extract sufficient commonality in implementations to make a universal verifier viable from the perspective of software complexity. This includes the question of whether the last mile effort to adapt a universal verifier to a particular system constitutes a sufficiently small fraction of total effort.

Whether existing E2EVV system authors and vendors are receptive to collaborating on a universal verifier (and using it as part of their complete solution), as well as participating in the possible standards emerging in the longer term.

Ideally many of these questions would be clarified during the initial stages of a prototype development as well as discussions with relevant parties

The post A Universal Approach to Election Verification: An Opportunity for Increased Trust in Elections appeared first on Sequent.

E-Voting Wasm Cryptography

Serhii Bohynia — Wed, 07 Dec 2022 07:46:37 +0000

The Sequent Voting Platform is an open-source E2EV internet voting system currently used in private organisations and non-legally binding elections of public organisations. The system employs standard cryptographic techniques following in the steps of well-established voting schemes proposed in the academic literature.

We demo core cryptographic components that are being developed for the next generation of Sequent’s platform. The main novelty demonstrated is the execution of (heavyweight) cryptographic operations in the browser, in a performant way. Potential applications of this technique are listed and possible benefits for security, privacy and verifiability are suggested.

Blog

E-Voting Wasm Cryptography

Blog, Technology

Add a header to begin generating the table of contents

Introduction

Like many other systems proposed in the literature, the closest ancestor in Sequent’s genealogy tree is Helios[1] in its original mixnet variant. The most significant departures from that Helios design are the use of a threshold distributed key generation mechanism, described in Pedersen[2] and featured in CGS[3] and Distributed Helios[4], and the use of a Terelius-Wikstrom[5] style mixnet rather than the Sako-Kilian[6] one. Other systems with which Sequent shares techniques are Wombat[7] and CHVote[8].

Research and development into Sequent’s next generation system is currently underway. Part of this effort has been centred around the use of Rust[9] as a core technology. One of the interesting aspects of this technology is its ability to target WebAssembly[10] through the LLVM[11] toolchain.

Internet voting systems require the use of a client component with which voters select and encrypt their votes, typically in a browser. In the past, these components have been written in Javascript or related languages. These components replicate some of the cryptography (for example, ElGamal encryption) that later processes votes in the backend. The initial motivating factor for our investigation of Rust’s WebAssembly target was the possibility of merging this overlapping cryptography into a single unified codebase. But there are further interesting possibilities.

Applications

Vote casting

Voting client software can reuse common cryptography packaged in a library compiled to Wasm, eliminating duplication.

Suggested benefits:

Security: A unified code base reduces the likelihood of mismatches between client and server cryptography, and reduces the attack surface. The amount of code that needs to be audited is also reduced.

Performance: Higher performance compared to Javascript implementations.

Ballot verification

Ballot verifiers implementing the Benaloh challenge can reuse common cryptography packaged in a library compiled to Wasm, eliminating duplication.

Suggested benefits: As above.

Election verification

Election verification, usually carried out by specialised software that must be downloaded and configured, can be executed in the browser with no installation.

Suggested benefits:

Verifiability: Making election verification procedures significantly more usable can achieve higher rates of exercised verification, moving the “universal” part of universal verifiability closer to practice.

Note that achieving performant implementations in this use case is particularly difficult as election verification involves compute intensive operations that a priori seem impossible in a browser. We have not listed performance as a benefit here as we are comparing with non-browser, native implementations; in other words, performance is a must-have rather than a benefit for this use case.

Trustee protocols

Running full trustee nodes on the browser with reduced deployment, administration and training costs.

Suggested benefits:

Real world experience has taught us that one of the barriers to running mixnet-based elections with a larger number of independent trustees is the cost that these trustees must incur in terms of deployment, administration and training. This is especially true for elections with fewer resources in human capital and infrastructure. As a result, it is not always easy to procure independent trustees to assume this important responsibility.

Any objective that is presumably achieved through distribution into independent trustees could be achieved to a greater degree when some of the costs of this distribution are reduced. For example:

Privacy: Ballot secrecy safeguards achieved through the distribution of private key material and mixing permutations would be achieved to a higher degree if more trustees participate.
Security: Correctness safeguards achieved through distribution of mixing and tallying would be achieved to a higher degree if more trustees participate.

See previous section regarding performance as a benefit.

Demonstration

We choose to demonstrate the most complex scenario described above, as it’s a proof of concept that also validates the rest of the comparatively simpler use cases. We show how trustee operations, both shuffling and decryption, can be run in the browser. We will also show that the resulting performance numbers fall within the threshold of practical applicability in small to medium elections.

As stated previously, achieving performant mixing in the browser is a particularly difficult task: this requires cutting edge technology that is currently experimental. Additionally, the full security implications of applying these techniques have to be analysed in detail.

You can access the demo directly from your web browser here [12] ** and you can also see a video of how the demo performs running in the browser below:

Note

This document was presented in its original form for the E-Vote-ID 2022 conference as a short paper for the Demo Session. You can find this short paper in the E-Vote-ID 2022 proceedings [13] at page 175.

References

[1] Helios: Web-based Open-Audit Voting
[2] Non-interactive and information-theoretic secure verifiable secret sharing
[3] A secure and optimally efficient multi-authority election scheme
[4] Distributed ElGamal à la Pedersen: Application to Helios
[5] Proofs of Restricted Shuffles
[6] Receipt-free mix-type voting scheme — a practical solution to the implementation of a voting booth
[7a] Wombat Voting
[7b] An Implementation of Dual (Paper and Cryptographic) Voting System
[8] CHVote Protocol Specification
[9] https://www.rust-lang.org/
[10] https://webassembly.org/
[11] https://llvm.org/
[12] https://strand_github_pages.sequentech.io/demo.html
[13] https://dspace.ut.ee/handle/10062/84432 (page 175)

The post E-Voting Wasm Cryptography appeared first on Sequent.