Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Crypto-Project-ENSTA/front-end/llms.txt

Use this file to discover all available pages before exploring further.

Every vote in Evoting passes through ten distinct stages, each designed so that the party handling it at that stage learns only what it needs to — and nothing more. The result is a system where voter identity and vote content are never held together by any single entity at any point in the process.

Full vote lifecycle

1

Registration

The voter submits their email address to register. The system generates two codes: N1, an authentication token, and N2, a verification token. The commissioner stores the cryptographic hash of N2 — not N2 itself — and holds the list of valid N1 tokens. The voter receives both codes and is responsible for keeping N2 private until they wish to verify their ballot after counting.
2

Authentication

When the voter is ready to vote, they submit their N1 token to /voters/check_n1. The administrator verifies the token against the commissioner’s N1 list. A successful check returns is_N1_exist: true, confirming the voter is eligible to cast a ballot. The N1 token is consumed — it cannot be reused to cast a second ballot.
3

Ballot creation

The voter selects a candidate from the ballot and enters their N2 code. The browser assembles a ballot message consisting of the (vote choice, N2) pair. This pair is what will ultimately be published for public verification after counting.
4

Blinding

Before the ballot is transmitted, the voter’s client applies a random blinding factor to the ballot message. The blinded ballot reveals nothing about the vote choice or the N2 code. The blinding factor is stored locally on the voter’s device and is never sent to any server.
5

Blind signing

The voter sends the blind ballot to the administrator. The administrator verifies the voter’s eligibility (confirmed in step 2), then signs the blind ballot using its private key. The administrator returns the blind signature without ever seeing the ballot content.
6

Unblinding

The voter’s client removes the blinding factor from the administrator’s signature. The result is a valid administrator signature on the original, unblinded ballot — mathematically equivalent to a direct signature, but produced without the administrator seeing the content. See How blind signatures protect voter privacy for a full explanation.
7

Encryption

The unblinded ballot (containing the vote choice, N2, and the administrator’s signature) is encrypted using the counter’s public key. Only the counter, using its private key after voting ends, can decrypt it. The encrypted ballot is submitted via POST /voters/submit_vote.
8

Anonymization

The encrypted ballot passes through the anonymizer before reaching the counter’s storage. The anonymizer strips all metadata that could link the ballot to the voter — including IP address and session information. From this point forward, the ballot has no connection to the voter’s identity.
9

Counting

After the voting period ends, the counter uses its private key to decrypt all submitted ballots. For each ballot, the counter:
  1. Verifies the administrator’s digital signature to confirm the ballot was legitimately signed.
  2. Passes the N2 value to the commissioner, which checks it against the stored N2 hashes.
  3. Confirms the N2 has not appeared in any previously processed ballot (preventing double counting).
Ballots that pass all three checks are added to the tally.
10

Publication and verification

All valid (N2, vote) pairs are published. Any voter can submit their personal N2 code to POST /results/verify-vote to confirm their ballot was counted. The N2 was never transmitted with any identity information, so this verification reveals nothing about who the voter is.

Separation of knowledge

The security of the flow depends on each party knowing only what it needs to perform its role.
EntityKnowsDoes not know
AdministratorVoter identity (via N1 check)Vote content — sees only the blind ballot
CounterDecrypted vote content and N2Which voter submitted the ballot
CommissionerValid N2 hashesVote choices or ballot content
No party holds both a voter’s identity and their vote choice. An attacker who compromises a single entity cannot link identity to vote.

Verification response statuses

After counting, voters use their N2 code to verify their ballot at /results/verify-vote. The response includes a status field with one of three values:
StatusMeaning
validThe ballot was found, the administrator’s signature passed verification, and the N2 hash matched the commissioner’s records. The vote was counted.
invalid_n2No ballot with the provided N2 was found in the published results. The ballot may not have been submitted, or the N2 entered may be incorrect.
invalid_signatureA ballot with the provided N2 was found, but the administrator’s signature did not pass cryptographic verification.
An invalid_signature status indicates that a ballot attributed to your N2 failed signature verification during counting. This means the ballot was either forged or modified after the administrator signed it. If you receive this status, report it to the election authority immediately — this is evidence of potential ballot tampering.
A found: false response with a null status means the N2 was not located in the published results at all. Check that you are entering the correct N2 code. If you are certain the code is correct and you successfully submitted a ballot, contact the election authority.

Build docs developers (and LLMs) love