Technical Specifications

Before Election

Three essential pre-election steps — labeled a, b, & c — must be completed (in any order) before the election can begin.

a. Compile Voter Roll

The Election Administrator is responsible for defining a list of eligible voters. Each voter is assigned a unique Voter Authentication Token ("Auth Token").

Auth Tokens, which can only be used once, are necessary for casting a vote. They are designed to be infeasible to guess and are only valid for a single election. The SIV Admin Software automatically generates these Auth Tokens with cryptographically secure randomness when an Admin adds a new voter.

These Auth Tokens are currently 10-character hexadecimal strings (e.g. 2378bf376d), which creates slightly over a trillion possibilities ($16^{10}$ = $2^{40}$). Attempting to brute force auth tokens is not currently a risk, because validating them is logged per IP address, and can be rate-limited.

All assigned Voter Auth Tokens are known to the Election Administrator. When the election begins, each Voter Auth Token will be shared with its designated voter. These Auth Tokens function like traditional API Authentication Tokens and should be kept confidential.

Election Administrators have the ability to invalidate individual Auth Tokens and generate new ones as necessary, such as in cases where a voter accidentally leaks or loses their Auth Token.

All used Auth Tokens can be audited after the election. SIV does not automatically publish the list of Auth Tokens and their corresponding voters, but it is up to each election administrator and jurisdiction's requirements whether this is published, shared with a select group (such as candidates & their political parties), or not at all.

Using random statistical sampling, as part of a "Risk Limiting Audit", only a small number of submitted votes need to be individually audited to achieve overwhelmingly high confidence that the outcome of an election was not changed due to attacks on auth tokens.

b. Finalize Ballot Content

As with traditional paper elections, the Election Administrator must finalize the questions and options that appear on the ballot.

The SIV Admin software provides both a user-friendly Point-and-Click Ballot Designer interface and a machine-readable JSON Schema interface for advanced editing.

Each ballot item should have a unique key, such as "president", "governor", "mayor", or "proposition_3".

SIV is fully compatible with alternative voting methods like Ranked Choice Voting and Approval Voting. Real-time user-interface feedback and invalid ballot prevention features make it easier to adopt these less familiar voting methods.

c. Register Privacy Protectors

The Election Administrator can enroll "Privacy Protectors", each adding additional assurance for voter privacy.

Election Administrators choose who to invite, and Privacy Protectors must also opt-in by accepting the invitation.

Privacy Protectors play a crucial role after all votes have been submitted, but they must be registered before the election starts. They individually anonymize votes and verify the SIV Zero-Knowledge Proofs to ensure vote integrity. Only after completing these vital steps do they collaborate to unlock the encrypted votes for the final tally.

To maintain the neutrality and credibility of election fairness, Privacy Protectors with competing interests can be chosen. One reasonable choice would be having one Privacy Protector nominated by each candidate's political party, plus the Election Administrator themselves.

Privacy Protectors do not need to trust each other and cannot secretly tamper with votes.

After all Privacy Protectors have been selected and accepted their invitations, they collectively perform a Decentralized Key Generation Ceremony to create a $t$-of-$n$ Threshold Public Key, each holding a fractional share of the corresponding Private Key. Here, $n$ is the total number of trustees, and $t$ is the configured threshold required to successfully use the private key, as chosen by the election administrator.

Vote privacy is protected even if individual Privacy Protectors are malicious or compromised, as long as no more than $t$ Privacy Protectors are compromised. For example, if the key is 4-of-5, up to 3 Privacy Protectors can be compromised, and privacy is still protected.

SIV currently uses the Pedersen DKG protocol first described in the 1992 paper "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing" (opens in a new tab) by Dr. Torben Pedersen. This protocol avoids ever centralizing the full key in any one location, and verifies that all ceremony members are following the protocol correctly.

SIV provides Privacy Protectors software to automatically run the ceremony for all participants, using cryptographically secure sources of randomness. Every Privacy Protector gets their own complete log of exactly each step taken. All private key material is stored in participants browsers' LocalStorage, as well as displayed visually for them to backup to additional locations.

At the end of the ceremony a test encryption is created and jointly decrypted, to test the ceremony's success.

SIV's Privacy Protectors software can be run entirely in the browser, from any relatively modern desktop, laptop, or smartphone, without requiring any installations.

Election Begins

Step 1. Invitations Sent to Voters

The election begins with Administrators delivering to each voter their Voter Auth Tokens.

The specific process for issuing Auth Tokens is up to Election Administrators and can include any combination of the following methods:

1. Verified email
2. Verified SMS messages
3. Verified physical mail letters
4. Drawn signature verification
5. Photo verification of Government IDs and/or selfies
6. IP address geolocation
7. Unique codes given in-person
8. Cryptographic public keys
9. Time-based One-Time Passwords

Each method has its own trade-offs in terms of (a) speed, (b) cost, (c) ease-of-use, (d) difficulty to attack, and (e) accessibility.

SIV is intentionally flexible and non-prescriptive on this point, to accommodate different elections' and jurisdictions' requirements.

For some voters, such as Overseas Voters who already receive invitations to vote via email, sticking with email alone might be sufficient. This can be augmented by also requiring additional factors like drawn signatures to improve upon existing processes.

For other voters that are easier to reach via physical mail, Election Administrators can choose to continue sending physical letters with unique codes per voter to verify their identity.

In this way, SIV can match the Voter Authentication requirements of existing processes, while upgrading the return ballot process to be faster, more accessible, and fully verifiable.

Regardless of the verification method used, the entire process should leave as much of a written audit trail as possible, for independent verification.

As already mentioned in Pre-A "Compile Voter Roll", Election Administrators have the ability to invalidate individual Voter Auth Tokens and generate new ones for remediation purposes, such as if a voter accidentally leaks or loses theirs.

The remediation process is designed to be flexible and adaptable to different situations and requirements, while maintaining the same level of security and verifiability as the initial voter authentication process.

Step 2. Voters Make Selections & Encrypt Their Vote

Once voters have been successfully authenticated, they can view their blank ballot.

They can make their selections with a simple point-and-click interface, similar to the ease of filling out a Google Form.

SIV seamlessly adds powerful security features for 1-person-1-vote authentication, cryptographic privacy, and end-to-end voter verifiability.

Encryption Overview

The SIV Voter software automatically encrypts each vote selection using Elliptic Curve ElGamal Encryption over the Ristretto255 prime-order subgroup of Curve25519 (IETF RFC 8031 (opens in a new tab)), offering a NIST-recommended security level of 128 bits and classified as a "SafeCurve".

The encryption's public key, which SIV calls the "Encryption Address", is the Threshold Public Key generated by the Privacy Protectors in the Pre-C Ceremony.

The following sections outline the steps involved in generating encrypted ciphertexts for each vote:

Voter's Device Generates a Secret Verification

Before encryption, the SIV Voter software automatically generates a cryptographically random and secret twelve digit decimal number, of the form ####-####-####, called a Voter Verification #.

This number is distinct from the Voter Auth Token. It is intentionally not known which voter any individual Verification # belongs to, other than to that voter themselves. This includes the Election Administrator and the SIV server.

It is used later, for Post Election Voter Verification, but is necessary to generate now so it can be included inside the encrypted ciphertext.

The SIV Voter software automatically stores the Verification # on the voter's device in the browser LocalStorage (opens in a new tab), so it can be retrieved later.

Aside on Verification # Collisions

Because the Verification # is generated privately and independently by each voter's device, there is a small risk of collisions. Since they are made of 12 decimal digits, there are $10^{12}$ (approximately $2^{40}$) distinct Verification #'s possible. Per the Birthday Problem, we can expect a collision after around $2^{40/2}$ votes, approximately one million.

A collision is not a critical issue, but only a slight inconvenience for the voters whose Verification #'s collide. Individual voter verification is still fully possible. Furthermore, Verification #'s are specific to a single election. Since many jurisdictions report vote-totals precinct-by-precinct, there is no adverse impact on privacy to segment Verification #'s to precincts as well. Even the largest cities rarely have precincts above 10,000 voters, so we expect Verification # collisions to be quite rare, and of low-impact.

Building the Vote Plaintext

When the Voter has made their selection, the SIV software concatenates a string ${verification}:${vote_selection}, e.g. 3476-7608-1222:Abraham Lincoln.

All ballot items use the same Verification #.

Encoding the Vote to a Ristretto Point

The SIV software then reversibly encodes the string to a point in the Ristretto255 elliptic curve prime-order subgroup by:

1. Generating a random array of 32 bytes
2. Overriding the first byte with the length l of the encoded string as a single 8-bit byte
3. Overriding bytes 2 through l + 1 with a UTF-8 byte encoding of the string.
4. Converting this length + encoded string + random bits to a hexadecimal string, and then checking if it is a valid Ristretto point. If it is not, the encode function loops back again to Step 1 to generate new random bits to try again until it succeeds, which is approximately 1/16th of the time.

This entire process of finding a valid encoding point can be completed in a single digit number of milliseconds.

ElGamal Encryption

SIV uses Elliptic Curve ElGamal Encryption, which uses the following formula to calculate two values:

Encrypted = Encoded + (ElectionPublicKey * RandomNonce)

and

Lock = (Generator * RandomNonce)

where:

• + is Elliptic Curve Point Addition
• * is Elliptic Curve Point Multiplication, a cryptographically hard one-way function
• RandomNonce is a cryptographically-secure random value, generated on the voter's device
• Generator is the subgroup's generator point.

The ciphertext is the tuple { Encrypted, Lock }, where each of these values are Ristretto Points converted to hex strings.

One ciphertext tuple is generated for each individual ballot item.

Items Left Blank Are Still Encrypted

To avoid leaking which items a voter chose to vote on or not, which could accidentally de-anonymize a voter later when ballots are unlocked, all items left blank on the ballot are encrypted with the vote selection set as the string BLANK.

Seamless Voter Experience

Although a lot happens under the hood, the complex privacy and verification pieces are handled automatically for the voter by the SIV Voter software.

This entire Selection & Encryption step can be completed in a web browser, using any desktop, laptop, or smartphone made in the last decade, without requiring any installations. If necessary, voters can even make use of borrowed devices.

All Vote Data Is Stored On the Voter's Device

For Post-Election Auditing, a "Detailed Encryption Receipt" is stored on the voter's device in their browser's LocalStorage.

This includes:

• the full ballot schema they were presented, with the specific wording of every question, description, and options
• the election's public key Encryption Address
• the voter's secret Verification #
• the plaintext of their vote selections
• their encoded Ristretto Points
• the individual Random Nonces used for encryption
• the resulting encrypted ciphertexts
• a timestamp of when everything was encrypted

Voters can delete this data if they want, but SIV defaults to storing it, to help with later verification, which can be done by the voter or via larger Risk-Limiting Audits.

None of this data — other than their encrypted ciphertexts — leaves voters' devices.

Step 3. Voters Submit Encrypted Votes

After the voter has reviewed their selections, they can press "Submit" to send their encrypted vote data, along with their unique Voter Auth Token, to the Election Administrator via the siv.org (opens in a new tab) server.

This looks like a standard POST request to https://siv.org/api/submit-vote (opens in a new tab), with a JSON body like:

{
  auth: "20bc371dc4",
  election_id: "1658271670580",
  encrypted_vote: {
    mayor: {
      encrypted: "fc88a5d7e3996bb26c59ea99101571c377e2a4dbb0834f22d30d35ebf990997c",
      lock: "28cb5650c9d9c3c3a93dac60d46702219ddd1f4c301287df7d6cbf6b27fdcc1a"
    }
  }
}

The SIV server automatically checks that the Voter Auth Token matches an eligible voter for that election, and that it hasn't already been used.

If it passes, the vote is added to a public list of all votes received so far.

The voter is sent a confirmation email that their encrypted vote has been received and accepted.

This lets the voter know their job is done. It also alerts them in case someone else somehow gained access to their Auth Token. And it serves as a written receipt that the vote was accepted, to allow for auditing.

Because of the strong encryption, the Election Administrator still has no way to know how individual voters choose to vote.

Voting Period Ends

Step 4. Votes Are Anonymized

The anonymization process, although conceptually straightforward, employs strong cryptographic techniques. Essentially, the objective is to shuffle the list of encrypted votes.

If the encrypted votes' order was simply permuted, anyone could easily see where the new ciphertext had moved to. To prevent this traceability, each vote undergoes re-encryption in a manner that provably decrypts to the same plaintext value but obscures any association with the initial encrypted vote.

However, this alone does not guarantee anonymity, as the shuffler would still possess knowledge of the vote permutations. To address this, multiple Privacy Protectors each perform a sequential shuffle, ensuring that no single party can know the complete shuffling order.

This cryptographic shuffle takes a list of encrypted votes as input and generates a shuffled list of re-encrypted votes as output. Crucially, this shuffle must enable external observers to verify the integrity of the shuffle. This is accomplished with a Zero-knowledge Proof, which confirms that the output list is a valid re-encryption of the input list, i.e. none of the underlying plaintexts were lost or modified.

We employ an algorithm derived from Dr. Andrew Neff's 2004 paper "Verifiable Mixing (Shuffling) of ElGamal Pairs" (opens in a new tab). The primary modification is replacing modular exponentiation with Elliptic Curve Point Multiplication.

The proofs of completeness, soundness, and zero-knowledge remain the same in the context of Elliptic Curve Point Multiplication, while this adaptation offers a far higher encryption strength (opens in a new tab) even with fast and concise key-sizes.

Step 5. Encrypted Votes Are Unlocked and Tallied

Now that the encrypted votes have been shuffled and re-encrypted, they can be safely decrypted without anyone knowing whose vote is whose.

But they need to be decrypted without leaking the secret key. Otherwise it could be used to decrypt the original encrypted votes, before they were shuffled.

This decryption is done in another decentralized ceremony, involving a sufficient threshold number of Privacy Protectors, with each Privacy Protector submitting a partial decryption of each vote.

Note that this decryption is also provable — meaning parties cannot cheat in such a way as to make the vote decrypt to something else without people knowing. These ZK Proofs of a Valid Partial Decryption are verifiable by everyone, and automatically checked by all the other Privacy Protectors & SIV Admin Server.

Once the votes are decrypted, their complete contents are shown to everyone, and it is trivial to tally them. The tally totals can be independently recounted, for confirmation.