I am trying1 to build a Proof Of Concept of a e-voting scheme on a blockchain. Before the elaboration, the question:
On a public e-voting, how do I keep the votes from being disclosed prematurely without a trustee?
The project works the following way:
- Noone trusts noone4, so no trustees at all.
- A "blockchain" here is a git-alike "merkle tree" where every entry has a hash of previous entry, a signer2, and some parameter(s). So it is a public immutable chain of records. Any change is immediately available to anyone.
- Anyone can issue a "statement" in form of a new record on the chain: Hereby me, by deadline of X, commit to implement the following, signed, me.
- Anyone else can vote on that statement (in a form of a permanent record as well). The privacy of identities of voters is irrelevant in this question (I'll be using Ring signatures)
- At some point, after the deadline, the tally has to be computed to permanently and in a deterministic way, verify the end result.
- I don't care if the votes values are disclosed after the tally, as the identities are hidden. I don't want voting progress to affect other votes, as majority wins points.
What I've researched:
- I can do the "commitment" scheme, when the voters disclose just the HMAC-SHA first, and then after the vote, disclose keys for that HMAC. But can this be done in just one phase? I want the voters to only interact once.
- I can try ElGamal, with help of homomorphism addition to sum the votes without disclosing them, OR-proof to prove validity of votes, Chaum–Pedersen3 to prove that summary computed tally is correct, but all of this, sadly, requires a trusted party, which I cannot afford.
- Shamir Secret Sharing, but a trustee still has to generate the secret. Anyone else still wouldn't be able to verify the votes.
- Any scheme when an original statement issuer can have access to individual votes, even if identities are hidden, corrupts the voting process, because the majority of the voters are going to be rewarded.
Footnotes:
- I am incapable of comprehending the math behind most of crypto schemes, and operate with those just as an end user.
- There's a CA administrator that can issue identities in form of encoded certificates as a record, signed by CA. Later on, those identities can sign entries of their own.
- This is sorcery to me, not sure even if it's possible.
- CA is assumed to not deny issuing, nor issue multiple identities to the same person. I am going to address that separately, by having an identity certificate (part of issuance process) to have a salted HASH of some external identity (e.g. a telegram account ID), so the same identity wouldn't be issued twice.