Nostr e-voting system using blinded ephemeral keys

Election Authority (EA) Platform

1.1 EA Administration Interface (Web-Based)

Purpose: Gives authorized personnel (e.g., election officials) a user-friendly way to administer the election.
Key Tasks:
1. Voter Registration Oversight: Mark which voters have proven their identity (via in-person KYC or some legal process).
2. Blind Signature Issuance: Approve or deny blind signature requests from registered voters (each corresponding to one ephemeral key).
3. Tracking Voter Slots: Keep a minimal registry of who is allowed one ephemeral key signature, and mark it “used” once a signature is issued.
4. Election Configuration: Set start/end times, provide encryption parameters (public keys), manage threshold cryptography setup.
5. Monitor Tallying: After the election, collaborate with trustees to decrypt final results and release them.

1.2 EA Backend Services

Blind Signature Service:
- An API endpoint or internal module that receives a blinded ephemeral key from a voter, checks if they are authorized (one signature per voter), and returns the blind-signed result.
- Typically requires secure storage of the EA’s blind signing private key.
Voter Roll Database:
- Stores minimal info: “Voter #12345 is authorized to request one ephemeral key signature,” plus status flags.
- Does not store ephemeral keys themselves (to preserve anonymity).
(Optional) Mix-Net or Homomorphic Tally Service:
- Coordinates with trustees for threshold decryption or re-encryption.
- Alternatively, a separate “Tally Authority” service can handle this.

2. Auditor Interface

2.1 Auditor Web-Based Portal

Purpose: Allows independent auditors (or the public) to:
1. Fetch All Ballots from the relays (or from an aggregator).
2. Verify Proofs: Check each ballot’s signature, blind signature from the EA, OTS proof, zero-knowledge proofs, etc.
3. Check Double-Usage: Confirm that each ephemeral key is used only once (or final re-vote is the only valid instance).
4. Observe Tally Process: Possibly see partial decryptions or shuffle steps, verify the final result matches the posted ballots.
Key Tasks:
- Provide a dashboard showing the election’s real-time status or final results, after cryptographic verification.
- Offer open data downloads so third parties can run independent checks.

2.2 (Optional) Trustee Dashboard

If the election uses threshold cryptography (multiple parties must decrypt), each trustee (candidate rep, official, etc.) might have an interface for:
- Uploading partial decryption shares or re-encryption proofs.
- Checking that other trustees did their steps correctly (zero-knowledge proofs for correct shuffling, etc.).

3. Voter Application

3.1 Voter Client (Mobile App or Web Interface)

Purpose: The main tool voters use to participate—before, during, and after the election.
Functionalities:
1. Registration Linking:
  - Voter goes in-person to an election office or uses an online KYC process.
  - Voter obtains or confirms their long-term (“KYC-bound”) key. The client can store it securely (or the voter just logs in to a “voter account”).
2. Ephemeral Key Generation:
  - Create an ephemeral key pair ((nsec_e, npub_e)) locally.
  - Blind (\npub_e) and send it to the EA for signing.
  - Unblind the returned signature.
  - Store (\npub_e) + EA’s signature for use during voting.
3. Ballot Composition:
  - Display candidates/offices to the voter.
  - Let them select choices.
  - Possibly generate zero-knowledge proofs (ZKPs) behind the scenes to confirm “exactly one choice per race.”
4. Encryption & OTS Timestamp:
  - Encrypt the ballot under the election’s public (threshold) key or produce a format suitable for a mix-net.
  - Obtain an OpenTimestamps proof for the ballot’s hash.
5. Publish Ballot:
  - Sign the entire “timestamped ballot” with the ephemeral key.
  - Include the EA’s blind signature on (\npub_e).
  - Post to the Nostr relays (or any chosen decentralized channel).
6. Re-Voting:
  - If the user needs to change their vote, the client repeats the encryption + OTS step, publishes a new ballot with a strictly later OTS anchor.
7. Verification:
  - After the election, the voter can check that their final ballot is present in the tally set.

3.2 Local Storage / Security

The app must securely store:
- Ephemeral private key ((nsec_e)) until voting is complete.
- Potential backup/recovery mechanism if the phone is lost.
- Blind signature from the EA on (\npub_e).
Potentially uses hardware security modules (HSM) or secure enclaves on the device.

4. Nostr Relays (or Equivalent Decentralized Layer)

Purpose: Store and replicate voter-submitted ballots (events).
Key Properties:
1. Redundancy: Voters can post to multiple relays to mitigate censorship or downtime.
2. Public Accessibility: Auditors, the EA, and the public can fetch all events to verify or tally.
3. Event Filtering: By design, watchers can filter events with certain tags, e.g. “election: 2025 County Race,” ensuring they gather all ballots.

5. Threshold Cryptography Setup

5.1 Multi-Seg (Multi-Party) Key Generation

Participants: Possibly the EA + major candidates + accredited observers.
Process: A Distributed Key Generation (DKG) protocol that yields a single public encryption key.
Private Key Shares: Each trustee holds a piece of the decryption key; no single party can decrypt alone.

5.2 Decryption / Tally Mechanism

Homomorphic Approach:
1. Ballots are additively encrypted.
2. Summation of ciphertexts is done publicly.
3. Trustees provide partial decryptions for the final sum.
Mix-Net Approach:
1. Ballots are collected.
2. Multiple servers shuffle and re-encrypt them (each trustee verifies correctness).
3. Final set is decrypted, but the link to each ephemeral key is lost.

5.3 Trustee Interfaces

Separate or integrated into the auditor interface—each trustee logs in and provides their partial key share for decrypting the final result.
Possibly combined with ZK proofs to confirm correct partial decryption or shuffling.

6. OpenTimestamps (OTS) or External Time Anchor

6.1 Aggregator Service

Purpose: Receives a hash from the voter’s app, anchors it into a blockchain or alternative time-stamping system.
Result: Returns a proof object that can later be used by any auditor to confirm the time/block height at which the hash was included.

6.2 Verifier Interface

Could be part of the auditor tool or the voter client.
Checks that each ballot’s OTS proof is valid and references a block/time prior to the election’s closing.

7. Registration Process (In-Person or Hybrid)

Voter presents ID physically at a polling station or a designated office (or an online KYC approach, if legally allowed).
EA official:
- Confirms identity.
- Links the voter to a “voter record” (Voter #12345).
- Authorizes them for “1 ephemeral key blind-sign.”
Voter obtains or logs into the voter client:
- The app or website might show “You are now cleared to request a blind signature from the EA.”
- Voter later (or immediately) generates the ephemeral key and requests the blind signature.

8. Putting It All Together (High-Level Flow)

Key Setup
- The EA + trustees run a DKG to produce the election public key.
Voter Registration
- Voter is validated (ID check).
- Marked as eligible in the EA database.
Blind-Signed Ephemeral Key
- Voter’s client generates a key, blinds (\npub_e), obtains EA’s signature, unblinds.
Voting
1. Voter composes ballot, encrypts with the election public key.
2. Gets OTS proof for the ballot hash.
3. Voter’s ephemeral key signs the entire package (including EA’s signature on (\npub_e)).
4. Publishes to Nostr.
Re-Voting (Optional)
- Same ephemeral key, new OTS timestamp.
- Final ballot is whichever has the latest valid timestamp before closing.
Close of Election & Tally
1. EA announces closing.
2. Tally software (admin + auditors) collects ballots from Nostr, discards invalid duplicates.
3. Threshold decryption or mix-net to reveal final counts.
4. Publish final results and let auditors verify everything.

9. Summary of Major Components

Below is a succinct list:

EA Admin Platform
- Web UI for officials (registration, blind signature issuing, final tally management).
- Backend DB for voter records & authorized ephemeral keys.
Auditor/Trustee Platforms
- Web interface for verifying ballots, partial decryption, and final results.
Voter Application (Mobile / Web)
- Generating ephemeral keys, getting blind-signed, casting encrypted ballots, re-voting, verifying included ballots.
Nostr Relays (Decentralized Storage)
- Where ballots (events) are published, replicated, and fetched for final tally.
Threshold Cryptography System
- Multi-party DKG for the election key.
- Protocols or services for partial decryption, mix-net, or homomorphic summation.
OpenTimestamps Aggregator
- Service that returns a blockchain-anchored timestamp proof for each ballot’s hash.

Additional Implementation Considerations

Security Hardening:
- Using hardware security modules (HSM) for the EA’s blind-signing key, for trustee shares, etc.
Scalability:
- Handling large numbers of concurrent voters, large data flows to relays.
User Experience:
- Minimizing cryptographic complexity for non-technical voters.
Legal and Procedural:
- Compliance with local laws for in-person ID checks, mandatory paper backups (if any), etc.

Final Note

While each functional block can be designed and deployed independently (e.g., multiple aggregator services, multiple relays, separate tally servers), the key to a successful system is interoperability and careful orchestration of these components—ensuring strong security, a straightforward voter experience, and transparent auditing.

naddr1qq…cnsu