cothority Additional votes in the structures

Additional votes in the structures

Open ineiti opened this issue 1 year ago • 1 comments

What this PR does

For a new election at EPFL there will be more than 8 candidates. This is a problem, as currently all choices are stored as data in an ed25519 Point. But as this Point only takes 24 bits of data, we cannot store easily more than 9 choices.

To allow for more than 9 candidates, each Ballot, Mix, and Partial will have Additional* fields to hold the additional choices. As these fields are slices, and added to the end of the structures, and thus to the end of the protobuf definition, it should be backward-compatible. To make sure we don't add security problems, we also do:

[x] fill up as many Additional fields in the Ballot as are maximally possible, to avoid leaking for how many candidates a person voted
[x] use shuffle/sequences.go if there are more than 9 candidates
[x] test if it works with one node down in shuffling / decryption
[ ] integration tests
- [ ] create a set of nodes for testing the frontend
- [ ] start with old version, set up an election, switch to new version, make sure it all works out

🙅‍ Friendly checklist:

[ ] 0. Code comments are added (or updated) when/where needed and explain the WHY of the code.
[ ] 1. Design choices, user documentation and any additional doc are added (or updated) in READMEs.
[ ] 2. Any new behaviour is tested and small units of code that can be are unit tested.
[ ] 3. Code comments are added on tests to explain what they do.
[ ] 4. Errors are systematically wrapped with a meaningful message using xerrors.Errorf and the %v verb.
[ ] 5. Hard limit of 80 chars is always respected.
[ ] 6. Changes are backward compatible.
[ ] 7. Indentation level does not exceed 5, although 4 is already suspicious.
[ ] 8. Functions, files, and packages are kept to a manageable size and decomposed into smaller units if needed.
[ ] 9. There are no magic values.