Technology 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.

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.

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.

Plaintext Encoding in ElGamal

Serhii Bohynia — Tue, 22 Nov 2022 07:52:33 +0000

In cryptography, ElGamal is an asymmetric cryptosystem in which public and private keys are used to encrypt communication between two parties.

ElGamal encryption plays a similar role to the more commonly known RSA and is easily adaptable to a variety of cryptographic groups, and is semantically secure provided that the DDH assumption holds. In the case of internet voting, ElGamal is usually instantiated over a multiplicative subgroup induced by a safe prime. This requires that plaintext data must be first encoded into this subgroup before it can be encrypted.

Blog

Plaintext Encoding in ElGamal

Blog, Technology

Add a header to begin generating the table of contents

In cryptography, ElGamal is an asymmetric cryptosystem in which public and private keys are used to encrypt communication between two parties.

To ensure ballot privacy, the Sequent voting system uses an ElGamal re-encryption mixnet. As mentioned above, protected data must first be encoded into the plaintext space in which ElGamal operates. The information can be encrypted once it has been encoded in this space. During decryption, the ciphertexts are decrypted first, and then the plaintexts are encoded back into the original data.

ElGamal’s plaintext (and ciphertext) space is a multiplicative subgroup Gq, for some choice of p, a safe prime modulus such that p = 2q + 1. In order to encode data, first convert it into an integer (a universal data type that can hold any information), and then map it into Gq. In a single ciphertext, the number of integers that can be encoded is determined by the order q of Gq, so we can map numbers from Zq into Gq.

As I couldn’t find any references describing this simple procedure well, I decided to write it myself.

Encoding With the Legendre Symbol

One reference we can find is this from Advances in Cryptology — EUROCRYPT 2017.

To begin with, when using a safe prime p = 2q + 1, the multiplicative subgroup Gq is the set of quadratic residues mod p, which makes the scheme semantically secure. Accordingly, we should use the simple m x (m/p) encoding procedure. But why is (m/p) x m guaranteed to be a quadratic residue? The reference contains hints, which we expand on below.

Step 1: the legendre symbol is defined as

When the input integers range from q to p, then there are only two possibilities for encoding.

The expression (m/p) x m reduces to leaving m unchanged (1 x m) or reversing its sign (-1 x m). In particular, if m is already a residue, then (m/p) x m is still a residue since (1 x m) = m.

Step 2: we have that

Step 3: the first supplement of the law of quadratic reciprocity states

since p is a prime, then p mod 4 has only two possible values (1 and 3), so

if p ≡ 3 (mod 4) then -1 is a nonresidue modulo p

Step 4: our modulus p is a safe prime p = 2q + 1, where q is also a prime. Meaning:

q = 1 mod 4 or q = 3 mod 4

Expanding each case[1]

*q = 1 mod 4 ⇒ **2q = 2 mod 4 ⇒ **2q + 1 = 3 mod 4 ⇒ *p = 3 mod 4

similarly

q = 3 mod 4 ⇒ 2q 4 = 6 mod 4 ⇒ 2q = 2 mod 4 ⇒ p = 3 mod 4

Therefore in both cases, for a safe prime p, we have

p = 3 mod 4

Now, in reverse order, we combine each of the previous four steps. By the step 4 we have:

p = 3 mod 4

which by step 3 implies that

-1 is a nonresidue modulo p

which by step 2 implies that

(-1 x m) is a residue if m is not a residue

which by step 1 implies that

(m/p) x m is a residue if m is not a residue

Also by step 1 we saw that

(m/p) x m = 1 x m is a residue if m is a residue

Therefore in all cases

(m/p) x m is a quadratic residue modulo p for a safe prime p = 2q + 1

which is what we set out to prove.

Helios and Univote Example Code

Using ElGamal encryption, let’s take a look at two open source e-voting projects, Helios by Ben Adida and UniVote by the Bern E-voting group. Due to the fact that the voting booth runs in the browser, the code is written in JavaScript. The ElGamal encoding of integers is found in Helios’ elgamal.jsfile, which is also included in Sequent’s voting booth.

var y = m.add(BigInt.ONE);
var test = y.modPow(pk.q, pk.p);
if (test.equals(BigInt.ONE)) {
this.m = y;
} else {
this.m = y.negate().mod(pk.p);
}

Due to the fact that the subgroup Gq does not include the value zero, the first line adds one to the input. Following these lines are the implementations of (m/p) x m encoding. As you may recall, the legendre symbol can take on either a value of 1 or a value of -1. In the case (1 x m), the first branch of the if statement leaves m unchanged. This second branch corresponds to changing the sign of m, the (-1 x m) case. Calculation of the legendre symbol is based on Euler’s criterion in the if statement

This shows that the javascript code is in effect calculating (m/p) * m. We can see a similar method in UniVote, the code is found here:

var one = leemon.str2bigInt("1", 2, 1);
var t1 = leemon.add(bigIntInZq, one);
var t2 = leemon.powMod(t1,
encryptionSetting.q, encryptionSetting.p);
if (leemon.equals(t2, one) == 1) {
return t1;
} else {
return leemon.sub(encryptionSetting.p, t1);
}

As before, we’re adding 1 and then branching according to Euler’s criterion. Unlike above, in this case we have the value p – m instead of (1 x m). Since modular congruence can be achieved by subtraction[2], then this can be done.

-m mod p = (0 — m) mod p = p — m mod p

So both expressions, -m and p — m are equivalent, mapping the input m to quadratic residue.

Example Values

Here we show some concrete encoding examples for small p. Let’s first print the values in G5 for a choice of safe prime 11 = (2 x 5) + 1.

The quadratic residues are thus G5 = {1, 3, 4, 5, 9}. Now let’s see if the encoded in the allowed range q=5 actually map to residues.

where we can see that the encoded values are indeed in G5. Let’s run another test for p = (2 x 11) + 1

Again, the encoding works.

In Summary

In this post we learned how ElGamal encrypts data by encoding it into the correct subgroup with the expression (m/p) x p, expressed as the legendre symbol. The properties of modular arithmetic also explain why this works. The Euler criterion was used to determine residuosity in two implementations of this technique. Last but not least, we examined some examples of subgroups and encodings for small p and q values.

References

[1] We are using two properties here

if a = b mod n, then k a = k b (mod n) for any integer k (compatibility with scaling)
if a* = b mod n, a1 + *a2 ≡ b1 + b2 (mod n) (compatibility with addition)

[2] Compatibility with subtraction,

if a1 = b1 mod n and a2 = b2 mod n, *then a1 — *a2 = b1 — b2 (mod n) (compatibility with subtraction)

The post Plaintext Encoding in ElGamal appeared first on Sequent.