Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evoting: ballots with two zero points in them stop shuffle from succeeding #2277

Closed
jeffallen opened this issue May 15, 2020 · 1 comment
Closed

Comments

@jeffallen
Copy link
Contributor

jeffallen commented May 15, 2020

I cast a ballot with Alpha and Beta set to suite.point(), i.e. the zero point.

The election could not be shuffled because:

2 20/15/05 14:35:20.411766000: service.go:788 (service.(*Service).verify)                                 - tls://localhost:7782 verify failed: invalid PairShuffleProof
2 20/15/05 14:35:20.411816000: skipchain.go:1268 (skipchain.(*Service).bftForwardLinkLevel0.func1)        - Verification function failed: go.dedis.ch/cothority/v3/evoting/service.(*Service).verify-fm f7b6750d-188d-5f48-93a9-d8fba9cc262d
E 20/15/05 14:35:20.411835000: protocol.go:192 (protocol.(*BlsCosi).runSubProtocols)                      - verification failed on root node

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:

	k0, c0 := lib.Encrypt(replyOpen.Key, []byte{})
	noise := cothority.Suite.Point().Pick(random.New())
	k0 = k0.Add(noise, k0)

	ballot := &lib.Ballot{
		User:  idUser1,
		Alpha: k0,
		Beta:  c0,
	}

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.

@ineiti
Copy link
Member

ineiti commented May 18, 2020

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.

jeffallen pushed a commit that referenced this issue May 19, 2020
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.)
@ineiti ineiti closed this as completed in f39e400 May 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants