Zero Knowledge Voting with Trusted Server

TL;DR

Yes, a zero knowledge proof of voting can be made using a trusted authentication server without requiring client-side cryptography. This relies on the server generating and managing cryptographic commitments and verifying proofs based on pre-defined rules. The user only needs to prove they have the authority to request a vote (via their existing login) and receive the result, not perform complex crypto operations themselves.

How it Works

This approach shifts the cryptographic burden to the trusted server. Here’s how it breaks down:

Authentication: The user logs in to the trusted authentication server using their normal credentials (username/password, MFA etc.). This establishes their identity.
Commitment Generation: Upon successful login, the server generates a unique cryptographic commitment for that user’s vote. Think of this as a secret ‘hash’ representing their potential vote. The server stores this commitment securely, linked to the user’s ID but without knowing the actual vote itself.
Vote Request: The user requests to cast their vote through the system.
Proof of Authority: The server verifies that the user is authenticated and has a valid commitment associated with their account. This proves they are allowed to vote once.
Zero Knowledge Proof (Server-Side): The server then performs a zero knowledge proof protocol to confirm the vote was cast without revealing the actual vote content. A common method is using Pedersen commitments and range proofs.
Result Verification: Other parties can verify that a valid vote has been cast, but they cannot determine who voted for what.

Step-by-Step Implementation

Here’s a practical guide to implementing this system:

Choose a Cryptographic Library: Select a library that supports Pedersen commitments and range proofs (e.g., libsnark, ZoKrates).
Commitment Generation (Server-Side): When a user authenticates:

Generate a random blinding factor ‘r’.
Choose a public commitment key ‘G’ and a vote option encoding ‘H’ (e.g., 0 for Option A, 1 for Option B).
Calculate the commitment: C = r * G + H.
Store ‘C’ associated with the user’s ID in your database.

Vote Request Handling (Server-Side): When a user requests to vote:

Retrieve the commitment ‘C’ for that user from the database.
Check if the commitment has already been used (prevent double voting).

Zero Knowledge Proof Generation (Server-Side): Use your chosen library to generate a proof demonstrating:

The user knows ‘r’ and ‘H’.
‘C = r * G + H’ holds true.
‘H’ is a valid vote option (e.g., 0 or 1).

Proof Verification (Server-Side & Public Verifiers): Verify the generated proof using the library’s verification functions.
// Example (Conceptual – Library Specific)
bool isValidProof = verifyProof(proof, commitment, publicParameters);

Tallying: The server can tally the votes by summing the ‘H’ values of all valid proofs. Because only the commitments are stored, individual vote privacy is maintained.

The server never knows which user cast which vote.
Public verifiers can confirm the total count without knowing individual votes.

Important Considerations

Trusted Server: The security of this system relies entirely on the trustworthiness of the authentication server. It must be protected against compromise.
Range Proofs: Ensure your range proof implementation correctly restricts vote options to a predefined set (e.g., 0 and 1).
Database Security: Protect the database storing commitments from unauthorized access or modification.
Scalability: Generating proofs can be computationally expensive. Consider optimizing your code and using efficient cryptographic libraries for large-scale deployments.

The post Zero Knowledge Voting with Trusted Server appeared first on Blog | G5 Cyber Security.