@ Brunswick

A Nostr-Based E-Voting System with Blinded Ephemeral Keys, OpenTimestamps, and Re-Voting 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 . This is the “one-time” identity used to sign ballots. The EA never learns the real identity behind 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 . 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 (). 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 . 2. Blinding The client blinds to produce . This ensures the EA cannot learn the real . 3. Blind Signature Request The voter, using their KYC-bound key (), sends 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 with its private key and returns the blinded signature. 4. Unblinding The voter’s client unblinds the signature, obtaining a valid signature on . Now 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 . 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 of the ballot data (ciphertext + ZKPs). The client sends to an OpenTimestamps aggregator. The aggregator returns a timestamp proof verifying that “this hash was seen at or before block/time .” 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 (the blind-signed ephemeral key). 4. A final signature by the voter’s ephemeral key 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 , 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 . 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 . Relays store both ballots, but the newer OTS timestamp shows which ballot is “final.” Rule: The final vote for ephemeral key 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 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 and . 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.