@ 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

@ c1e9ab3a:9cb56b43

# 1. Introduction Modern election systems must balance **privacy** (no one sees how individuals vote) with **public verifiability** (everyone can confirm the correctness of the tally). Achieving this in a decentralized, tamper-resistant manner remains a challenge. Nostr (a lightweight protocol for censorship-resistant communication) offers a promising platform for distributing and archiving election data (ballots) without relying on a single central server. This paper presents a design where: 1. Each *voter* generates a **new ephemeral Nostr keypair** for an election. 2. The election authority (EA) **blind-signs** this ephemeral public key (npub) to prove the voter is authorized, without revealing which voter owns which ephemeral key. 3. Voters cast *encrypted ballots* to Nostr relays, each carrying an **OpenTimestamps** proof to confirm the ballot’s time anchor. 4. **Re-voting** is allowed: a voter can replace a previously cast ballot by publishing a *new* ballot with a *newer* timestamp. 5. Only the *latest valid ballot* (per ephemeral key) is counted. We combine well-known cryptographic primitives—**blind signatures**, **homomorphic or mix-net encryption**, **threshold key management**, and **time anchoring**—into an end-to-end system that preserves anonymity, assures correctness, and prevents double-voting. --- # 2. Roles and Components ## 2.1 Voters - **Long-Term (“KYC-bound”) Key**: Each voter has some identity-verified Nostr public key used only for official communication with the EA (not for voting). - **Ephemeral Voting Key**: For each election, the voter **locally generates** a new Nostr keypair \((nsec_e, npub_e)\). - This is the “one-time” identity used to sign ballots. - The EA never learns the real identity behind \(\npub_e\) because of **blinding**. ## 2.2 Election Authority (EA) - Maintains the **official voter registry**: who is entitled to vote. - **Blind-Signs** each valid voter’s ephemeral public key to authorize exactly one ephemeral key per voter. - Publishes a **minimal voter roll**: e.g., “Voter #12345 has been issued a valid ephemeral key,” without revealing which ephemeral key. ## 2.3 Nostr Relays - Decentralized servers that store and forward events. - Voters post their ballots to relays, which replicate them. - No single relay is critical; the same ballot can be posted to multiple relays for redundancy. ## 2.4 Cryptographic Framework 1. **Blind Signatures**: The EA signs a blinded version of \(\npub_e\). 2. **Homomorphic or Mix-Net Encryption**: Ensures the content of each ballot remains private; only aggregate results or a shuffled set are ever decrypted. 3. **Threshold / General Access Structure**: Multiple trustees (EA plus candidate representatives, for example) must collaborate to produce a final decryption. 4. **OpenTimestamps (OTS)**: Attaches a verifiable timestamp proof to each ballot, anchoring it to a blockchain or other tamper-resistant time reference. --- # 3. Protocol Lifecycle This section walks through **voter registration**, **ephemeral key authorization**, **casting (and re-casting) ballots**, and finally the **tally**. ## 3.1 Registration & Minimal Voter Roll 1. **Legal/KYC Verification** - Each real-world voter proves their identity to the EA (per legal procedures). - The EA records that the voter is eligible to cast one ballot, referencing their long-term identity key (\(\npub_{\mathrm{KYC}}\)). 2. **Issue Authorization “Slot”** - The EA’s voter roll notes “this person can receive exactly one blind signature for an ephemeral key.” - The roll does *not* store an ephemeral key—just notes that it can be requested. ## 3.2 Generating and Blinding the Ephemeral Key 1. **Voter Creates Ephemeral Key** - Locally, the voter’s client generates a fresh \((nsec_e, npub_e)\). 2. **Blinding** - The client blinds \(\npub_e\) to produce \(\npub_{e,\mathrm{blinded}}\). This ensures the EA cannot learn the real \(\npub_e\). 3. **Blind Signature Request** - The voter, using their **KYC-bound key** (\(\npub_{\mathrm{KYC}}\)), sends \(\npub_{e,\mathrm{blinded}}\) to the EA (perhaps via a secure direct message or a “giftwrapped DM”). - The EA checks that this voter has not already been issued a blind signature. - If authorized, the EA signs \(\npub_{e,\mathrm{blinded}}\) with its private key and returns the blinded signature. 4. **Unblinding** - The voter’s client unblinds the signature, obtaining a **valid signature** on \(\npub_e\). - Now \(\npub_e\) is a **blinded ephemeral public key** that the EA has effectively “authorized,” without knowing which voter it belongs to. 5. **Roll Update** - The EA updates its minimal roll to note that “Voter #12345 received a signature,” but does *not* publish \(\npub_e\). ## 3.3 Casting an Encrypted Ballot with OpenTimestamps When the voter is ready to vote: 1. **Compose Encrypted Ballot** - The ballot can be **homomorphically** encrypted (e.g., with Paillier or ElGamal) or structured for a **mix-net**. - Optionally include Zero-Knowledge Proofs (ZKPs) showing the ballot is valid (one candidate per race, etc.). 2. **Obtain OTS Timestamp** - The voter’s client computes a **hash** \(H\) of the ballot data (ciphertext + ZKPs). - The client sends \(H\) to an **OpenTimestamps** aggregator. - The aggregator returns a **timestamp proof** verifying that “this hash was seen at or before block/time \(T\).” 3. **Create a “Timestamped Ballot” Payload** - Combine: 1. **Encrypted ballot** data. 2. **OTS proof** for the hash of the ballot. 3. **EA’s signature** on \(\npub_e\) (the blind-signed ephemeral key). 4. A final **signature** by the voter’s ephemeral key \((nsec_e)\) over the entire package. 4. **Publish to Nostr** - The voter posts the complete “timestamped ballot” event to one or more relays. - Observers see “an event from ephemeral key \(\npub_e\), with an OTS proof and the EA’s blind signature,” but cannot identify the real voter or see the vote’s contents. ### 3.4 Re-Voting (Updating the Ballot) If the voter wishes to revise their vote (due to coercion, a mistake, or simply a change of mind): 1. **Generate a New Encrypted Ballot** - Possibly with different candidate choices. 2. **Obtain a New OTS Proof** - The new ballot has a fresh hash \(H'\). - The OTS aggregator provides a new proof anchored at a *later* block/time than the old one. 3. **Publish the Updated Ballot** - Again, sign with \(\npub_e\). - Relays store both ballots, but the *newer* OTS timestamp shows which ballot is “final.” **Rule**: The final vote for ephemeral key \(\npub_e\) is determined by the ballot with the **highest valid OTS proof** prior to the election’s closing. ## 3.5 Election Closing & Tally 1. **Close Signal** - At a specified time or block height, the EA publishes a “closing token.” - Any ballot with an OTS anchor referencing a time/block *after* the closing is invalid. 2. **Collect Final Ballots** - Observers (or official tally software) gather the *latest valid* ballot from each ephemeral key. - They confirm the OTS proofs are valid and that no ephemeral key posted two different ballots with the **same** timestamp. 3. **Decryption / Summation** - If homomorphic, the system sums the encrypted votes and uses a **threshold** of trustees to decrypt the aggregate. - If a mix-net, the ballots are shuffled and partially decrypted, also requiring multiple trustees. - In either case, individual votes remain hidden, but the final counts are revealed. 4. **Public Audit** - Anyone can fetch all ballots from the Nostr relays, verify OTS proofs, check the EA’s blind signature, and confirm no ephemeral key was used twice. - The final totals can be recomputed from the publicly available data. --- # 4. Ensuring One Vote Per Voter & No Invalid Voters 1. **One Blind Signature per Registered Voter** - The EA’s internal list ensures each real voter only obtains one ephemeral key signature. 2. **Blind Signature** - Ensures an *unauthorized* ephemeral key cannot pass validation (forging the EA’s signature is cryptographically infeasible). 3. **Public Ledger of Ballots** - Because each ballot references an EA-signed key, any ballot with a fake or duplicate signature is easily spotted. --- # 5. Security and Privacy Analysis 1. **Voter Anonymity** - The EA never sees the unblinded ephemeral key. It cannot link \(\npub_e\) to a specific person. - Observers only see “some ephemeral key posted a ballot,” not the real identity of the voter. 2. **Ballot Secrecy** - **Homomorphic Encryption** or **Mix-Net**: no one can decrypt an individual ballot; only aggregated or shuffled results are revealed. - The ephemeral key used for signing does not decrypt the ballot—the election’s threshold key does, after the election. 3. **Verifiable Timestamping** - **OpenTimestamps** ensures each ballot’s time anchor cannot be forged or backdated. - Re-voting is transparent: a later OTS proof overrides earlier ones from the same ephemeral key. 4. **Preventing Double Voting** - Each ephemeral key is unique and authorized once. - Re-voting by the same key overwrites the old ballot but does not *increase* the total count. 5. **Protection Against Coercion** - Because the voter can re-cast until the deadline, a coerced vote can be replaced privately. - No receipts (individual decryption) are possible—only the final aggregated tally is revealed. 6. **Threshold / Multi-Party Control** - Multiple trustees must collaborate to decrypt final results, preventing a single entity from tampering or prematurely viewing partial tallies. --- # 6. Implementation Considerations 1. **Blind Signature Techniques** - Commonly implemented with RSA-based Chaumian blind signatures or BLS-based schemes. - Must ensure no link between \(\npub_{e,\mathrm{blinded}}\) and \(\npub_e\). 2. **OpenTimestamps Scalability** - If millions of voters are posting ballots simultaneously, multiple timestamp aggregators or batch anchoring might be needed. - Verification logic on the client side or by public auditors must confirm each OTS proof’s integrity. 3. **Relay Coordination** - The system must ensure no single relay can censor ballots. Voters may publish to multiple relays. - Tally fetchers cross-verify events from different relays. 4. **Ease of Use** - The user interface must hide the complexity of ephemeral key generation, blind signing, and OTS proof retrieval—making it as simple as possible for non-technical voters. 5. **Legal Framework** - If law requires publicly listing which voters have cast a ballot, you might track “Voter #12345 used their ephemeral key” without revealing the ephemeral key. Or you omit that if secrecy about *who voted* is desired. 6. **Closing Time Edge Cases** - The system uses a *block/time anchor* from OTS. Slight unpredictability in block generation might require a small buffer around the official close. This is a policy choice. --- # 7. Conclusion We propose an **election system** that leverages **Nostr** for decentralizing ballot publication, **blinded ephemeral keys** for robust voter anonymity, **homomorphic/mix-net encryption** for ballot secrecy, **threshold cryptography** for collaborative final decryption, **OpenTimestamps** for tamper-proof time anchoring, and **re-voting** to combat coercion. **Key Advantages**: 1. **Anonymity**: The EA cannot link ballots to specific voters. 2. **One Voter, One Credential**: Strict enforcement through blind signatures. 3. **Verifiable Ordering**: OTS ensures each ballot has a unique, provable time anchor. 4. **Updatability**: Voters can correct or override coerced ballots by posting a newer one before closing. 5. **Decentralized Audit**: Anyone can fetch ballots from Nostr, verify the EA’s signatures and OTS proofs, and confirm the threshold-decrypted results match the posted ballots. Such a design shows promise for secure, privacy-preserving **digital elections**, though real-world deployment will require careful **policy, legal, and usability** considerations. By combining cryptography with decentralized relays and an external timestamp anchor, the system can uphold both **individual privacy** and **publicly auditable correctness**.