Encryption of ballot selection in the vote

[JanisErdmanis]

The PeaceFounder voting system works fine without encrypting the vote before sending it over to the tally. However, encryption of the vote selection can be added with seemingly no extra assumptions. In particular, the failure of the collector to decrypt the votes is equivalent to saying that the votes have been deleted from their system. In both cases, the blamed party is unchanged, and the result is the same - unpublished votes.

Encrypted votes can help maintain the imparity of auditors/proxies through which votes are routed in case of collector failures. The TOR exit node is another involved party where imparity would be necessary so that it wouldn't become an avenue for network sabotage for those who don't vote in a particular way.

Another use of selection encryption is that it could enable coerced vote tagging. In situations where the voter anticipates that their coercer will watch from the back or will take their device and ask for credentials, the voter can produce a decoy PIN code, which works as an ordinary one except for the fact that the votes cast with it would be tagged as coerced and thus not counted. If previously a vote had been cast without a coercion tag, it would be counted instead. For this to work, the coercer should not know that the voter had created a decoy PIN code, as then he could ask for both of them. An unlimited number of decoy PIN codes should be allowed to be created. An alternative is that every wrong PIN code could be considered a decoy PIN code with which a vote would be tagged as coerced.

To implement vote encryption, we shall recognise the two failure modes we need to protect against:

• The voter encrypts a jibberish and blames the collector for incorrectly decrypting.
• The collector spoils the vote by claiming that the vote has been encrypted incorrectly.

To protect against these introduced threat vectors, we need a proof of correct decryption.

The simplest way to encrypt the vote is to use collector public key C <- g^x as a means to establish a secret key on the client as K<-C^y, which can be hashed and then used with symmetric encryption. The voter sends back V<-g^y along the symmetric encryption, from which the collector can derive the symmetric key. In this scenario, at the end of the vote, the collector could prove that it has decrypted the vote correctly by publishing zero-knowledge proof that log_C K = log_g V, which is doable but overly complicated.

We can use the fact that the encryption is only needed temporarily. The collector creates a sacrificial public key S<-g^s and distributes it to voters before they cast their vote. That can be done in the same way as the commit is distributed currently. After the vote, the collector would publish s, allowing everyone to verify a correct decryption.

To act on this proposal, we will need to encrypt the selection for the vote:

struct Vote
    proposal::Digest
    seed::Digest
    enc::EncryptedSelection
    seq::Integer
    sig::Seal
end

struct EncryptedSelection
    S::Pseudonym
    V::Pseudonym
    cyphertext::Vector{UInt8}
end	

Notice that the sequence number nor the signature is encrypted. The signature must be left unencrypted as that allows everyone whose vote is eligible to be included in the ballot box to verify that, which is essential for accountability. The link between the pseudonym and the voter is secret; thus, disturbing the voting experience for those who would usually not vote in a certain way is impossible. The sequence number, on the other hand, can be left in the open as it is only trying to establish an order for votes in the final tally and thus is of no importance for maintaining imparity.