1
$\begingroup$

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:

  1. I am incapable of comprehending the math behind most of crypto schemes, and operate with those just as an end user.
  2. 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.
  3. This is sorcery to me, not sure even if it's possible.
  4. 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.
$\endgroup$
3
  • 1
    $\begingroup$ "Noone trusts noone, so no trustees at all" has limits. Among others: whatever makes a public key valid must be trusted to not assign two keys to the same entity, else this entity will have two voting rights. Independently, there is the issue of trusting participants to not sell their votes; that's something that traditional voting systems mitigate by making it hard to determine what a bribed person actually voted, thus making it possible for that bribed person to cash the bribe to vote for A, and vote for B. $\endgroup$
    – fgrieu
    Commented Jul 7, 2022 at 10:50
  • $\begingroup$ @fgrieu Right, there some CA assumptions, yes that statement is not correct. I am going to address that separately. I can see bribing to be a problem, I have partially mitigate it by hiding the identity of the voter thru RingCT, but I am willing to see how big of a problem it is going to be. The system is going to have penalty for voting "incorrectly", aka if you vote an event didn't happen, but majority stated it did, you get fined with points. The main concern rn is to not disclose the votes too soon, as there is an incentive to vote majority. $\endgroup$
    – desertkun
    Commented Jul 7, 2022 at 13:02
  • $\begingroup$ Indeed you need a trusted dealer to do Shamir secret sharing, but it's also possible to distribute the dealer. Does your model allow that? If so then something like Belenios hal.inria.fr/hal-02066930/document might be something you're looking for. $\endgroup$
    – lamba
    Commented Jul 9, 2022 at 22:13

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.