@ Brunswick

# 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**.