VeriAnonVote

Verifiable Anonymous Voting System Based on Linkable Ring Signatures

Demo version URL

You need to use the Tor browser to open it.

中文版

1. Project Introduction

This project is an open-source, full-stack solution aimed at providing a secure, anonymous, and verifiable electronic voting system. It utilizes Linkable Ring Signature technology, specifically an implementation of BLSAG (Back's Linkable Spontaneous Anonymous Group signatures), to ensure voter privacy during the voting process, prevent fraudulent activities (such as double voting), and allow for public verification of election results.

Core Advantages:

• Strong Anonymity: As long as a voter's private key is not compromised, the probability of linking any specific ballot to a voter's identity, even with fully public voting results, is 1/{number of registered voters}.
• Verifiability: The entire election process and results are auditable and verifiable, relying on modern cryptographic guarantees and publicly auditable voter registration records.
• Fraud Prevention: Linkable ring signature technology detects and prevents repeated voting using the same identity (private key).
• Key Compromise Response: Even if a voter's private key is unfortunately stolen, the attacker cannot prevent the voter from discovering the unauthorized vote and requesting the revocation of the voting record associated with that key.
• Tor Network Support: Provides Tor Onion Service configuration, allowing server deployment without a public IP or domain name, and enforcing access through the Tor network to enhance anonymity.

2. Core Technical Concepts

Understanding how this system works requires familiarity with the following key cryptographic concepts:

2.1 Asymmetric Encryption (Public-Key Cryptography)

This is the foundation of modern secure communication and digital signatures. Each user (in this system, a voter or poll participant) possesses a pair of keys:

• Public Key (PK): Can be distributed publicly. In this system, verified voter public keys are collected and published to form the "ring" and verify signatures.
• Secret Key (sk): Must be kept strictly confidential by the user (voter). Used to generate digital signatures to express voting intent.

Core Security Assumption: Based on current computational capabilities (practical quantum computers are not yet available), deriving the private key from the public key is infeasible. For sufficiently strong keys (e.g., 256-bit or higher), the time and financial cost required to crack them, even with supercomputers, are astronomical and practically impossible.

2.2 Ring Signature

A ring signature is a special type of digital signature scheme that allows a signer to:

1. Select a set of public keys (called a "ring") that includes their own public key.
2. Use their own private key to sign a message (e.g., ballot content), with the signature representing the entire "ring".
3. A verifier can use the public keys of all members in the ring to validate the signature, confirming that the signature indeed came from one member of the ring.

Key Feature: Unconditional Anonymity Although the verifier can confirm the signature's validity, they cannot determine which specific member of the ring generated it. In a voting scenario, this means each voting act is obscured among all eligible voters (ring members), making it untraceable to the specific voter.

2.3 Linkable Ring Signature - BLSAG

Linkable Ring Signatures (this project uses a BLSAG implementation) add a crucial feature to standard ring signatures: Linkability.

• Duplicate Detection: If the same signer (possessing the same private key) signs multiple messages (casts multiple votes) under the same specified context (e.g., for the same voting issue in the same election), the signatures generated by them can be "linked" together using a public algorithm.
• Identity Remains Anonymous: This linking operation only reveals that "these signatures came from the same person" but still does not expose the specific identity (public key) of that signer.

Application Effect: This mechanism effectively detects and prevents malicious double voting without sacrificing voter anonymity.

3. System Roles

This system defines four main roles:

1. Voter Registrar:
   • Responsible for running the voter registration server.
   • Collects and stores the public keys of eligible voters confirmed by Verifiers.
   • Publishes the final list of public keys used to form the ring signature.
   • Operational Note: This role can be undertaken by government agencies, independent committees, or credible private companies/organizations, or even individuals, provided that the evidence recorded during registration (which can later prove the registrant's eligibility and that it's their first registration) cannot be forged and is properly stored, available for download and audit by any third party.
2. Verifier:
   • Authorized by the Voter Registrar.
   • Responsible for verifying the identity and eligibility of voters applying for registration.
   • Ensures the registration process is verifiable (e.g., through video recording) to prevent duplicate registrations.
   • Uses their own credentials (e.g., Ethereum wallet signature) to sign a proof, confirming voter eligibility and uploading the voter's public key to the Voter Registrar.
   • Operational Note: Similar to the Registrar, the Verifier role can also be handled by authorized private entities. The key is the standardization, transparency, and auditability of the verification process.
3. Voter:
   • Possesses a unique key pair (Public Key PK, Secret Key sk).
   • Proves identity and eligibility to a Verifier to complete registration, getting their public key included in the ring.
   • Uses their private key to create a linkable ring signature for their ballot.
   • Uploads the ring signature to the Election Organizer's server, or securely prints it as a QR code to be mailed or dropped into a ballot box anonymously.
   • Properly backs up and secures their private key.
4. Election Organizer:
   • Responsible for running the election voting server.
   • Obtains the final voter public key ring from the Voter Registrar.
   • Receives and stores the (signed) ballots submitted by voters.
   • Publishes the tally results (list of signatures and corresponding vote content).
   • Note: This role is typically separated from the Voter Registrar for separation of powers but can be handled by the same trusted entity.

4. System Workflow

1. Preparation Phase:
   • Voter Registrar collects and authorizes the identifiers (e.g., ETH addresses) of Verifiers.
   • Voter Registrar starts and runs the voter registration server.
2. Voter Registration Phase (Critical Step):
   • Voter uses a client application to generate their key pair (PK, sk) and mnemonic phrase, and must securely back up the mnemonic phrase.
   • Voter presents their public key (PK) and proof of eligibility documents to a Verifier.
   • Verifier strictly verifies the Voter's identity and eligibility, making a verifiable record (e.g., recording a video including facial information, public key QR code, and identity proof) to prevent the same person from registering multiple times for multiple voting qualifications. All registration records (including verification evidence like video links or hashes) should be publicly available for review and audit.
   • After confirmation, Verifier uses their credentials (e.g., ETH wallet) to sign a proof message containing the Voter's public key.
   • Verifier uploads the Voter's public key along with their signed proof to the Voter Registrar's server.
   • (Optional Online Registration Process): Voter can self-record a video containing credible identity information and their public key, upload it to a public platform (like YouTube/Twitter), and share the link with a Verifier. The Verifier, after reviewing and backing up the video, performs the aforementioned signing and uploading duties. This method particularly considers the needs of governments in exile or geographically dispersed organizations.
3. Registration Closure and Public Key Ring Publication:
   • After the registration period ends, the Voter Registrar compiles all verified voter public keys into the final "public key ring" and publishes it. This ring is the basis for subsequent voting.
4. Election Voting Phase:
   • Election Organizer starts the election server and obtains the public key ring from the address specified by the Voter Registrar.
   • Voter selects their voting option in the client application and uses their private key (sk) and the public key ring to create a linkable ring signature (BLSAG) for the ballot content.
   • Voter uploads the generated signed ballot to the Election Organizer's server.
5. Tallying and Auditing Phase:
   • After voting ends, the Election Organizer publishes all received valid signed ballot records.
   • Anyone can:
     • Use the public key ring to verify the validity of each ballot signature.
     • Use BLSAG's linking algorithm to check for duplicate votes cast by the same (unknown) identity. Duplicate votes should be considered invalid.
     • Audit the process by cross-referencing with the public voter registration records to ensure the initial construction of the public key ring was trustworthy, complete, and did not omit eligible voters or include ineligible ones.

5. Security and Trustworthiness Logic Argument

The security and trustworthiness of this system are built upon a series of cryptographic axioms and system design premises.

Premises and Axioms:

• Axiom 1 (Asymmetric Encryption - Key Pair Security): For sufficiently strong key pairs (e.g., 256-bit and above), deriving the secret key (sk) from the public key (PK) is computationally infeasible with current technology.
• Axiom 2 (Asymmetric Encryption - Signature Unforgeability): Only the holder of the secret key (sk) can generate a valid digital signature that can be verified by the corresponding public key (PK).
• Axiom 3 (Ring Signature - Correctness): A valid ring signature S generated for message M using the secret key sk_i of a member whose public key PK_i is in ring R, can always be verified using all public keys in ring R.
• Axiom 4 (Ring Signature - Anonymity): Given a valid ring signature S, message M, and public key ring R, it is computationally infeasible to determine which specific member's secret key in ring R generated the signature S.
• Axiom 5 (Linkable Ring Signature - Linkability): If the same secret key sk_i is used to generate two signatures S1 and S2 within the same linking context (e.g., the same election E), a public algorithm can easily detect that S1 and S2 originate from the same signer, without revealing the signer's specific identity.
• Axiom 6 (Linkable Ring Signature - Unforgeability): An attacker who does not possess the secret key of any member in ring R cannot generate a valid (linkable) ring signature for message M that can be verified using ring R.
• Premise 1 (System Design - Voter Registration Integrity and Transparency): The voter registration process is public, transparent, and strictly enforced. This ensures: (a) Only eligible voters can register; (b) Each eligible voter has only one public key included in the final public key ring R; (c) All records of the registration process (including identity verification evidence) are available for public audit; (d) The final public key ring R is public, accurate, and complete. This is the cornerstone of the entire system's trustworthiness.
• Premise 2 (User Behavior - Private Key Security): Each voter securely stores their private key (sk) and does not share it with others.

Logical Proofs:

1. Proof: Voting is anonymous when the voter's private key is not compromised.

   • A voter uses their private key sk_i and the public key ring R to sign ballot M, generating S (per workflow).
   • The signature S is valid and can be publicly verified (per Axiom 3).
   • According to Axiom 4 (Ring Signature Anonymity), even if S, M, and R are public, an external party cannot link S to any specific public key PK_j in R (including PK_i).
   • Conclusion: As long as the voter's private key sk_i is not compromised (Premise 2), their voting act is anonymous relative to other members in ring R.

2. Proof: No external party (including the Election Organizer) can forge or tamper with a vote when the voter's private key is not compromised.

   • Assume an attacker (not a ring member, or another ring member j) wants to forge voter i's vote M, casting a forged vote M' for another candidate.
   • For the forged vote M' to be accepted, the attacker must generate a valid signature S' using ring R that verifies correctly.
   • According to Axiom 6 (Ring Signature Unforgeability), generating such an S' requires possessing the private key of at least one member of ring R.
   • Since voter i's private key sk_i is not compromised (Premise 2), and the attacker is not voter i, the attacker does not possess sk_i.
   • If the attacker is another ring member j, they can use their own sk_j to generate a signature, but this represents their own voting intent, not a forgery of voter i's vote.
   • If the attacker is an external party, they do not possess any private key from a member of R.
   • Conclusion: Given private key security, there is no way to forge a valid ballot representing a specific voter's intent (if it could even be determined) or a ballot that doesn't belong to any ring member.

3. Proof: The system can detect and prevent double voting.

   • Assume voter i (or someone who stole their private key) attempts to cast two votes, M1 and M2, using the private key sk_i in the same election E, generating signatures S1 and S2.
   • According to Axiom 5 (Linkable Ring Signature - Linkability), a public algorithm can detect that S1 and S2 were generated by the same (but unknown) private key within the same linking context (election E).
   • The Election Organizer or any auditor running this linking algorithm can identify this pair (or multiple pairs) of linked signatures.
   • System rules can dictate that any set of linked signatures are considered invalid votes.
   • Conclusion: Linkability ensures that any attempt to vote multiple times using the same identity (private key) can be detected, thus preventing double votes from being counted as valid.

4. Proof: Even if a voter's private key is stolen, the voter can detect it and seek remedy, preventing unintended votes from being counted.

   • Assume voter i's private key sk_i is stolen, and the thief uses sk_i to cast a vote M', generating signature S', and submits it to the Election Organizer.
   • All voting records S' (and their corresponding M') are publicly transparent.
   • Voter i can review the public voting records. Although they cannot directly see who cast S' (anonymity), they can detect an anomaly in the following ways:
     • If they haven't voted yet, but find a record in the system with a key image identical to the one generated by their key pair.
     • If they have also cast their own vote S, then S and S' will be linked because they originate from the same private key sk_i (Axiom 5). Seeing this link confirms to voter i that their private key was compromised.
   • Upon detecting the anomaly, voter i can immediately report the key theft and the existence of the non-consensual vote S' to the Election Organizer (e.g., by contacting the election committee or even publicly broadcasting on social media).
   • After verifying voter i's identity and the report, the organizer can mark S' as invalid.
   • Simultaneously, the system could allow voter i to express their true voting intention through other verified means (e.g., traditional voting under supervision).
   • Conclusion: Transparency and linkability allow the legitimate voter to detect non-consensual votes cast with a stolen private key and provide avenues for requesting revocation and remedy, although this relies on timely detection and effective out-of-band communication mechanisms.

Important Note: All the security guarantees mentioned above strongly depend on Premise 1, the fairness, transparency, and strict execution of the voter registration process. If the registration stage is flawed (e.g., allowing ineligible individuals to register, permitting one person to register multiple public keys, failing to effectively prevent identity theft, incomplete or non-public registration records), then the legitimacy and trustworthiness of the election results will be fundamentally undermined, even if the subsequent cryptographic voting process is flawless. Therefore, designing and implementing a reliable, public, and auditable voter registration and verification process is crucial, arguably even more important than the voting technology itself.

6. Current Status and Future Outlook

• Current Status: This project is currently in the prototype stage. Core functionalities have been implemented, but it has not undergone sufficient optimization, extensive testing, or professional security auditing. It is currently NOT recommended for use in any official election or voting activity with significant impact.
• Target Users (Current Stage): Primarily intended for trial, iteration, and contribution by technically inclined groups, such as:
  • Computer science students and researchers
  • Free software developers and enthusiasts
  • NGOs, unions, associations needing anonymous voting mechanisms
  • Professional polling agencies/companies (media groups)
• Future Goals:
  1. Security Hardening: Undergo comprehensive code audits from the open-source community and professional security firms to fix potential vulnerabilities.
  2. Attack Resistance: Enhance the system's resistance to common network attacks like Distributed Denial of Service (DoS).
  3. Usability Improvement: Develop extremely user-friendly open-source voter clients, ensuring average voters can easily and securely complete registration and voting without specialized knowledge.
  4. Performance Optimization: Optimize the efficiency of signature generation, verification, and linking algorithms, as well as the storage efficiency of voting data, ensuring acceptable performance even when voter numbers reach hundreds of thousands or millions (e.g., using techniques like pre-hashing to optimize ring signature performance).
  5. Improve Documentation & Deployment Guides: Provide clear, complete documentation and deployment instructions.

Ultimate Vision: To develop this project into a mature, reliable, battle-tested solution capable of supporting state-level or even national political elections, truly realizing secure, anonymous, and verifiable democratic voting practices.

7. Features & To-Do List

This project currently implements the core anonymous voting workflow, but significant work remains to reach production-level standards.

Core Features (Implemented)

• Basic Infrastructure: Implemented basic interaction logic for the voter_registrar, verifier, voter, election_organizer roles.
• Key Management: Client supports key pair and mnemonic phrase generation.
• Voter Registration: Supports verifier validation, signing, and uploading of voter public keys.
• Online Registration Flow: Supports registration via submission of video links containing identity information.
• Ring Signature Core: Implemented BLSAG-based linkable ring signature generation and verification.
• Voting Process: Supports voters signing ballots with their private keys and submitting them.
• Tallying & Publication: Election organizer can receive ballots and publish voting records.
• Double Voting Detection: Utilizes BLSAG linkability to detect multiple votes from the same private key.
• Tor Network Support: Provides veri_anon_vote_server.torrc config file for deployment and access via Onion Service.

Code Quality & Maintainability (To-Do)

• Documentation Improvement: Add detailed comments and documentation for all modules, major functions, and complex logic.
• Backend Refactoring & Abstraction: Review the existing backend code structure, refactor as necessary to improve modularity and reduce coupling.
• Frontend Refactoring: Refactor the AI-generated frontend code, establish clear structure, state management, and standards; add documentation and tests.

Performance Optimization (To-Do)

• Ring Signature/Verification Performance Optimization (Pre-Hashing):
  • Research and implement a Pre-Hashing scheme to significantly reduce signing/verification time for large ring sizes.
  • (Later) Add mechanisms to verify the correctness of the Pre-Hash computation process.
• Algorithmic Complexity Optimization: Identify and optimize algorithms with excessive complexity (e.g., those scaling exponentially with user count).
• Storage Optimization: Optimize the storage methods for voter registration info and voting results to reduce redundancy and improve efficiency.

Security Hardening (To-Do)

• Dependency Library Security Audit: Conduct security reviews or professional audits of all third-party libraries, especially cryptographic ones.
• DoS Attack Resistance: Analyze attack surfaces and implement mitigation measures like rate limiting and request validation.

Usability & User Experience (To-Do)

• Real Clients: Develop actual client applications for the other three roles besides the Voter.
• Private Key Leak Detection Mechanism: Allow voters to detect key compromise by checking public records for their key image or linked signatures, even without voting themselves.
• Client Usability: Develop more user-friendly desktop or mobile clients for average users.
• Error Handling & Feedback: Improve error handling in clients and servers, providing clearer prompts.

Testing (To-Do)

• Unit Tests: Write comprehensive unit tests for core modules.
• Integration Tests: Design and implement integration tests.
• Stress Tests: Conduct stress tests to evaluate performance and stability.

8. Installation and Usage

8.1 Tor Network Deployment

This project provides an example Tor configuration file veri_anon_vote_server.torrc. Running the server-side components using this configuration offers the following advantages:

• No Public IP or Domain Needed: The server can be accessed via a Tor Onion Service v3 address, eliminating the need to purchase a public IP and domain name.
• Enhanced Anonymity: Forces all clients (voters) to connect to the server via the Tor network, further hiding voters' real IP addresses and improving anonymity protection.
• Built-in Encryption & Authentication: Tor Onion Service v3 addresses inherently contain the service's public key. Client connections automatically verify this, mitigating risks associated with potentially compromised or forged certificates from traditional Certificate Authorities (CAs) in HTTPS.

Configuration Method: TODO

9. License

Apache-2.0 license

10. Participation and Contributions

Join the Discussion Room

11. Donations and Support

If you want to support me, please consider donating to support the development.

Paypal: https://paypal.me/RyderFreeman4Logos

monero: 4AhAFwmzX1FgZRwWokLRJ6WenbH9MWpVPMjATPg15Mvp81AUwchWfRX9XFNuQ2Loxg2V8KTogCAPTZTe6JYXA9JPMDaTWhp