1

Noob here. Was reading this: https://karl.tech/learning-solidity-part-2-voting/

From my basic understanding, a hash function:

  • Receives an input (like x) and spits some result (like y)

  • y is calculated upon the contents of x (so the same x will always hash to the same y)

  • It's non reversible (if you have y, you cannot get x)

Sounds good, but think about the following scenario.

There's an election on an Ethereum Smart Contract with 3 Candidates:

  1. C1

  2. C2

  3. C3

Same logic:

  • Voter can't know who other Voters voted for. Results must only be revealed after the election is over.

  • To vote, each voter must distribute their hash.

  • Once all votes are submitted/election period is over, all voters distribute their actual vote.

  • Then you can verify that the Distributed Vote hashes to the previously Distributed Hash, and the vote can be counted. Sounds good.

But in a Smart Contract Election scenario:

  • All voters know the name/id/label of the 3 candidates.

  • All voters have access to the Smart Contract's code and can see which hash function was used.

Couldn't the voters just:

  1. Run the hash function for each candidate name/id/label by themselves

  2. Write down the resulting hash for each candidate (it would be the same for each candidate every time, right?)

  3. Go see which hashes are distributed in the Blockchain and reverse engineer who each person voted for?

I don't really know that much, so this might be a stupid question.

1

I think you missed this part:

In this implementation, a vote for choice1 will take the form: 1-my_secret_password and a vote for choice2 will take the form: 2-my_other_secret_password

Notice that the 1 and 2 are the actual votes. The passwords are included to make sure votes remain secret until the reveal period. Each vote is required to use a unique password. If two votes were to use the same password, then the vote commits will be the same. If the vote commits are the same, then only one vote will be counted!

This is exactly to prevent what you are describing. You basically create a random number locally and this will be included in the hash computation. No one else knows this number, so no one can reverse engineer it.

| improve this answer | |
  • I read again and now I understand it better: the hash won't be "reverse-engineerable" because an unknown password was included. But do you really need a unique password for each vote? "1-password123" and "2-password123" will still hash to different things. Or do you mean you will only need unique passwords if you are voting for the same candidate multiple times? – antoniopgs Jun 29 at 23:38
  • @antoniopgs After the election you reveal your password(s), so any following elections should use completely different passwords. Before you reveal any password, you could in theory use similar ones. Just know that once you reveal one password, all other votes with similar passwords could be guessed. – Markus - soliditydeveloper.com Jun 29 at 23:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.