You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I instead encrypted an empty ballot, thus putting a correct ElGamal encryption of no data into Alpha and Beta, then the shuffle succeeded. So it seems that the shuffle verification can only succeed if the input is correct. But it is not clear how the system can protect itself from incorrect input from ballots.
Update:
There is a difference in the result, depending on if the points are perturbed randomly, or are equal to zero:
This ballot can be shuffled, even though it is an invalid encryption. It can be decrypted, though extracting the ballot from it via Point.Data() can fail due to the embedding length being wrong, but that's a graceful failure.
So it seems like zero points are the problem, not random points. Why would that be? If we are sure that zero points are the only problematic cases, of course we can protect from that in the Ballot cast verifier run on each node.
The text was updated successfully, but these errors were encountered:
Can't you do the shuffle-proof on one single vote? So when casting a vote, every node will verify that it can shuffle the vote with it's own private key. This shuffling is only used for verification and then discarded.
Fixes#2277.
Also: Fix an uncaught panic in Skipchain, because the result of
recover() is no longer of type string. (No idea how long this has
been a latent bug.)
I cast a ballot with Alpha and Beta set to suite.point(), i.e. the zero point.
The election could not be shuffled because:
When I instead encrypted an empty ballot, thus putting a correct ElGamal encryption of no data into Alpha and Beta, then the shuffle succeeded. So it seems that the shuffle verification can only succeed if the input is correct. But it is not clear how the system can protect itself from incorrect input from ballots.
Update:
There is a difference in the result, depending on if the points are perturbed randomly, or are equal to zero:
This ballot can be shuffled, even though it is an invalid encryption. It can be decrypted, though extracting the ballot from it via Point.Data() can fail due to the embedding length being wrong, but that's a graceful failure.
So it seems like zero points are the problem, not random points. Why would that be? If we are sure that zero points are the only problematic cases, of course we can protect from that in the Ballot cast verifier run on each node.
The text was updated successfully, but these errors were encountered: