DEV Community: Sazid Ahmed

I Built a Blockchain Voting System with RSA Encryption — Here's How It Works

Sazid Ahmed — Fri, 06 Mar 2026 13:10:22 +0000

Digital voting is one of those problems that sounds simple until you actually think about it.

How do you prove a vote was counted?
How do you stop someone from voting twice?
How do you make results auditable without exposing who voted for whom?

I built a full-stack university voting system that answers all three — using cryptography as the enforcer, not just policy. Here's how it works under the hood.

The Stack
Frontend → React + Vite (port 5173)
Admin Panel → React + Vite (port 5174)
Backend API → Node.js + Express (port 3000)
Institution → Node.js API (port 4000)
Blockchain → 4-node custom network (ports 3001–3004)
Database → MySQL 8 (port 3306)
DB UI → phpMyAdmin (port 8080)

All containerized with Docker Compose. Spin it up with one command.

The Core Problem: Why Not Just Use a Database?
A SQL database is mutable. An admin can UPDATE votes SET candidate_id = 2 WHERE candidate_id = 1 and nobody would know. Even with audit logs, those logs can be edited too.

A blockchain is append-only and distributed. Every vote is a transaction. Every transaction is hashed and linked to the previous one. Tamper with one block, and every subsequent hash breaks — detectable by every other node in the network.

That's the foundation. Now let's look at what happens when someone actually casts a vote.

The Vote Casting Flow

The Page Loads — Keys Are Fetched Silently When a voter navigates to the voting page, the app fetches their cryptographic keypair in the background. Once ready, the UI confirms: ✓ Cryptographic Keys Loaded Your vote will be encrypted and digitally signed.

This isn't just a status message. It's a hard gate — you can't submit without it.

The Voter Selects a Candidate
Standard radio button UI. Clean, accessible. Nothing unusual here.
Submit — The Crypto Kicks In
This is where it gets interesting. Before any network request is made, the frontend does three things:

Step 1 — Build the payload

Step 2 — Encrypt it
The payload is encrypted with the election's RSA public key using OAEP padding:

Only the election authority holds the matching private key. The server never sees the plaintext vote.

Step 3 — Sign it

The encrypted payload is signed with the voter's private key:

This proves authenticity — the vote came from this voter — without linking the voter to their candidate choice.

The Receipt After the blockchain records the transaction, the voter gets a receipt:

The nullifier is the key innovation here. It's a cryptographic commitment derived from the voter's identity and the election ID — unique enough to detect double votes, but revealing nothing about the actual vote.

Double-Vote Prevention Try to vote again in the same election:

You have already voted in this election.

Two-layered enforcement:

On-chain — The nullifier is stored on the blockchain. If the same nullifier appears twice, the transaction is rejected at the consensus level.
Application layer — The backend checks the nullifier in the database before even submitting to the chain.
Neither layer alone is sufficient. Together they're airtight.

The Blockchain Network
Four nodes run in Docker containers. Each node:

Maintains a full copy of the chain
Participates in block consensus
Validates incoming transactions (vote receipts)

Nodes discover each other via peer discovery on startup. A vote isn't confirmed until it's accepted by the network — no single node can fabricate or alter a result.

Privacy by Design — Not by Policy
The system is designed so that it is architecturally impossible to correlate a voter's identity with their candidate choice — even by the developers.

What's public

That a vote was cast
The transaction hash
The nullifier
The final tally

What's private

Who the vote was for
The plaintext vote payload
The voter-candidate mapping
Individual choices

This separation isn't achieved through access controls or database permissions. It's enforced by the cryptography itself.

Running It Locally

That's it. All 10 containers start automatically:

What I'd Do Differently
Zero-knowledge proofs instead of nullifiers. A nullifier is good. A ZK-SNARK is better — it lets you prove "I am eligible to vote and haven't voted yet" without revealing any identity information at all. It's significantly more complex to implement, but the privacy gain is substantial.

On-chain tallying. Right now, tallying happens off-chain in the backend. A smart contract approach where tallying is computed on-chain would eliminate the last remaining trust assumption.

Threshold decryption. Currently a single election authority holds the decryption key. Splitting that key across multiple authorities using Shamir's Secret Sharing would prevent any single party from decrypting votes prematurely.

Key Takeaway
The big lesson from this project: don't use access controls where you could use cryptography.

Access controls say "you're not allowed to see this." Cryptography says "you literally cannot see this." One requires trust in the system operator. The other doesn't.

In a voting system — where the entire point is that no one has to trust anyone — that difference is everything.

Have questions about the architecture, the crypto primitives, or the blockchain consensus mechanism? Drop them in the comments — happy to dig in.

Building the Registration and Login Flow for My Blockchain Voting System

Sazid Ahmed — Tue, 03 Mar 2026 11:03:23 +0000

When people hear about a blockchain voting app, they usually think about ballot encryption, digital signatures, vote verification, and blockchain integrity.

Those parts matter, but before any of them can be trusted, the system has to solve a simpler problem first:

How do we make sure only valid users can register and log in?

For my university voting system, I designed the registration and login flow to start with institutional identity verification instead of a normal open signup form.

Why I Didn’t Use a Regular Signup Flow
In a standard web app, users usually enter a name, email, and password and create an account immediately.

That approach is too weak for a voting system.

I wanted registration to be tied to an institutional source of truth, so the process starts with a university-issued ID. The user cannot just type arbitrary profile data and create an account.

Instead, the app verifies the ID against the institution members directory and loads the official record from there.

Registration Flow
The registration process in my app has three steps.

1. Verify institution ID
The user enters their student, teacher, or staff ID.

The backend checks that ID against the institutional directory. If the record exists, the system loads the official member information such as:

full name
institutional email
role
department

This means identity data comes from the directory, not from free-form user input.

2. Verify institutional email with OTP
After the ID is confirmed, the system sends a 6-digit OTP to the institutional email address linked to that member record.

The OTP flow includes a few controls:

code expires after 10 minutes
maximum 3 verification attempts
60-second cooldown before requesting another code
verified OTP is consumed after successful registration

This adds a second proof that the person registering is actually connected to the institutional identity.

3. Set password and create account
Once the OTP is verified, the user sets a password and completes registration.

At that point, the backend creates the user account using the verified institutional data. The registration process also prepares the account for the secure voting flow by associating cryptographic key material with the user.

So registration is doing more than account creation. It is also establishing identity and preparing the user for secure participation in the system.

How I Prevent Duplicate Registration
Preventing duplicate registration was a key part of this design.

In a voting system, duplicate registration is not just a usability issue. It is a trust issue.

I handled it in multiple layers:

the institution directory tracks whether a member is already registered
the frontend can identify already-registered members early
before sending OTP, the backend checks whether the institution ID already exists
during final registration, the backend checks again by institution ID and email
after successful registration, the member is marked as a registered voter

I prefer this layered approach because critical checks should not rely on only one screen or one database query.

Login Flow
After registration does the heavy trust-building work, login stays simple.

The user logs in with:

institution ID
password

The backend then:

checks whether the user exists
verifies the password
issues a JWT token
returns the authenticated user profile

That token is used to access protected features like elections and voting operations.

I intentionally kept login straightforward because the identity validation has already happened during registration.

Why This Matters
One of the biggest lessons from building this part of the project is that secure systems depend heavily on their entry points.

Blockchain and cryptography can protect voting operations, but they do not fix a weak registration process.

If the wrong users can register, or if identity is not validated properly, the trust model starts with a flaw.

That is why I spent time designing registration and login as part of the security architecture, not just the user onboarding flow.

Closing
This registration and login design helped me connect:

institutional identity verification
OTP-based email validation
duplicate-registration prevention
authenticated access with JWT.

For me, this became a reminder that in systems like digital voting, trust starts long before the first vote is cast.

It starts at registration.

Building the Institution Members Module for My Blockchain Voting App

Sazid Ahmed — Mon, 02 Mar 2026 10:49:39 +0000

One of the less flashy but most important parts of my blockchain voting application is the Institution Members module.

When people hear "blockchain voting system", they usually think about encrypted ballots, signatures, audit logs, and blockchain-based integrity. Those parts matter, but before any of that works, the system has to solve a more basic problem:

How do we make sure only valid institution members can register?

That question is why I built this module.

Why I Needed This Feature
A voting application cannot use a normal open signup flow.

If anyone can register with arbitrary identity data, the trust model becomes weak from the start. In this project, I wanted registration to begin from a controlled institutional directory instead of trusting user-entered details.

So I created an Institution Members feature that acts as the eligibility source for account creation.

It stores records like:

institution ID
full name
institutional email
role
department
year level
voter registration status

This means registration is tied to known institutional data rather than self-declared identity.

How It Works in the Registration Flow
The module is directly connected to the registration process.

The flow looks like this:

A user enters their institution ID.
The backend looks up that ID in the institution directory.
If the record exists, the system loads the official member data.
If the member is already registered, the process stops and the user is asked to log in.
If the member is eligible, the system sends an OTP to the official institutional email.
After OTP verification, the user sets a password and completes registration.
The backend creates the voter account using the verified directory data.
The member is marked as a registered voter in the directory.

This design avoids trusting identity fields typed manually by the user.

Why OTP Verification Matters
A valid institution ID alone should not be enough to register.

Someone might know another person’s ID, so I added OTP verification to the institutional email address associated with that record. That gives the system a second proof that the registrant is actually linked to the institutional identity.

It is a simple mechanism, but it makes the registration boundary much stronger.

How I Prevent Duplicate Registration
Duplicate registration was one of the key problems I wanted to solve.

In this module, I handle it in multiple layers:

the institution directory tracks whether a member is already registered using a voter status flag
the frontend shows registered members as unavailable
the backend checks whether the institution ID already exists before sending OTP
the backend checks again during final registration using both institution ID and email
the institution directory enforces unique institution IDs and emails
after successful registration, the member is marked as a voter to block future attempts

I prefer this layered approach because registration integrity should not depend on a single UI check or one database lookup.

What I Learned
This module reminded me that secure systems are often shaped by the parts that seem ordinary.

A directory lookup, a status flag, an OTP check, and a uniqueness constraint may not sound as interesting as blockchain logic, but these controls define who is allowed into the system at all.

And in a voting app, that matters a lot.

For me, this was a useful reminder that trust starts before vote casting. It starts at registration.

Closing
The Institution Members module became one of the core trust layers in my blockchain voting project. It helped me connect institutional eligibility, email verification, and duplicate prevention into a registration flow that is much harder to abuse.

I’ll be sharing more modules from the system next, including how registration connects to the actual voting flow.

University Voting System (Blockchain Based)

Sazid Ahmed — Mon, 02 Mar 2026 10:36:21 +0000

I’m excited to start sharing my project updates, beginning with the overall application I’ve been building: a blockchain-based voting system designed for secure, transparent, and privacy-focused digital elections.
The application brings together multiple components into one complete ecosystem:

a voter-facing frontend
a backend API for election and user management
a custom blockchain node for vote record integrity
an admin panel for managing elections
an institution API for identity-related workflows
monitoring tools for system health and observability

The goal of this project is not just to create an online voting app, but to build a system that addresses the bigger challenges of digital voting:

voter authentication
ballot privacy
vote integrity
double-vote prevention
auditability
verifiability

So far, the application supports the core voting flow, including registration, login, election creation, vote casting, and result viewing. It also includes cryptographic protections, audit logging, Docker-based deployment, and monitoring support.

What makes this project especially interesting to me is that it sits at the intersection of software engineering, cybersecurity, cryptography, and system design. It’s been a strong learning experience in building something that needs to be functional, secure, and trustworthy at the same time.
Starting tomorrow, I’ll share the system module by module and explain the features and functionality of each part in more detail.