@ c1e9ab3a:9cb56b43

# 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) 1. **Voter presents ID** physically at a polling station or a designated office (or an online KYC approach, if legally allowed). 2. **EA official**: - Confirms identity. - Links the voter to a “voter record” (Voter #12345). - Authorizes them for “1 ephemeral key blind-sign.” 3. **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) 1. **Key Setup** - The EA + trustees run a DKG to produce the **election public key**. 2. **Voter Registration** - Voter is validated (ID check). - Marked as eligible in the EA database. 3. **Blind-Signed Ephemeral Key** - Voter’s client generates a key, blinds \(\npub_e\), obtains EA’s signature, unblinds. 4. **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. 5. **Re-Voting** (Optional) - Same ephemeral key, new OTS timestamp. - Final ballot is whichever has the latest valid timestamp before closing. 6. **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: 1. **EA Admin Platform** - Web UI for officials (registration, blind signature issuing, final tally management). - Backend DB for voter records & authorized ephemeral keys. 2. **Auditor/Trustee Platforms** - Web interface for verifying ballots, partial decryption, and final results. 3. **Voter Application (Mobile / Web)** - Generating ephemeral keys, getting blind-signed, casting encrypted ballots, re-voting, verifying included ballots. 4. **Nostr Relays (Decentralized Storage)** - Where ballots (events) are published, replicated, and fetched for final tally. 5. **Threshold Cryptography System** - Multi-party DKG for the election key. - Protocols or services for partial decryption, mix-net, or homomorphic summation. 6. **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. nostr:naddr1qqxnzde5xq6nzv348yunvv35qy28wue69uhnzv3h9cczuvpwxyargwpk8yhsygxpax4n544z4dk2f04lgn4xfvha5s9vvvg73p46s66x2gtfedttgvpsgqqqw4rs0rcnsu