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

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.

dedis / cothority

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