Cast-as-Intended Mechanism with Return Codes Based on PETs

We propose a method providing cast-as-intended verifiability for remote electronic voting. The method is based on plaintext equivalence tests (PETs), used to match the cast ballots against the pre-generated encrypted code tables. Our solution provides an attractive balance of security and functional properties. It is based on well-known cryptographic building blocks and relies on standard cryptographic assumptions, which allows for relatively simple security analysis. Our scheme is designed with a built-in fine-grained distributed trust mechanism based on threshold decryption. It, finally, imposes only very little additional computational burden on the voting platform, which is especially important when voters use devices of restricted computational power such as mobile phones. At the same time, the computational cost on the server side is very reasonable and scales well with the increasing ballot size.

💡 Research Summary

The paper presents a novel cast‑as‑intended (CAI) verification mechanism for remote electronic voting that leverages plaintext equivalence tests (PETs) and return codes. The authors observe that existing return‑code schemes either impose heavy computational loads on voter devices, rely on a small set of trusted parties, or lack a fine‑grained distributed trust model. To address these issues, they propose a system built on well‑known cryptographic primitives: ElGamal encryption over a safe‑prime group, threshold key generation and decryption, and a zero‑knowledge PET protocol that can prove that two ciphertexts encrypt the same plaintext without revealing the plaintext itself.

In the setup phase, a set of n tellers jointly generate a public election key (pk_e) and a public code key (pk_c) using a (t‑out‑of‑n) threshold scheme; at most t‑1 tellers may be corrupted. An auxiliary public key (pk_a) is also generated for non‑threshold encryption of auxiliary data. The printing facility creates a ballot sheet for each voter, containing an authentication code, a finalisation code, a confirmation code, and for each voting option two pre‑generated return codes (one for “yes”, one for “no”). These return codes are encrypted under pk_c and published as an encrypted code table.

During voting, the voter authenticates to the voting server, selects options on a possibly compromised client, and the client encrypts the selected choices under pk_e, producing a ballot ciphertext. The ballot is sent to the server, which forwards it to the tellers. The tellers jointly perform a PET between the ballot ciphertext and the encrypted code table entries. Because PET reveals only equality of plaintexts, the tellers can determine which return‑code entries correspond to the voter’s encrypted choices without learning the choices themselves. The appropriate return codes are then sent back to the voter (either via the same client or an independent channel). The voter compares these codes with those printed on the ballot sheet; a match confirms that the encrypted ballot reflects the intended choices. The voter then sends the finalisation code, after which the server records the ballot and issues a confirmation code.

The scheme offers several advantages. First, the client performs only a single PET regardless of ballot size, making it suitable for low‑power devices such as smartphones. Second, the distributed trust model ensures that an attacker must corrupt at least t tellers to break CAI, a stronger guarantee than schemes that rely on two fixed roles. Third, server‑side computation is essentially constant per ballot, scaling well with the number of options, unlike PGD‑based approaches that require one PET per option. The authors also provide a formal security analysis showing that, under the standard Decisional Diffie‑Hellman (DDH) assumption and the correctness of the PET protocol, the scheme achieves CAI, ballot secrecy (provided the printing channel is trusted), and integrity of the return‑code generation.

The paper does not claim receipt‑freeness; a voter who reveals the printed return codes could still be coerced, which is a common limitation of most return‑code systems. Moreover, the scheme assumes a trusted printing facility and secure delivery of ballot sheets; this assumption is shared with other return‑code proposals but remains a practical challenge. The authors also discuss related work, comparing their approach to PGD, Norwegian e‑voting projects, the Swiss Neuchâtel system, and a recent Geneva Internet voting proposal that uses oblivious transfer. They demonstrate an attack on the Geneva scheme: a malicious client can supply correct return codes while submitting a malformed ballot that later passes verification only after tallying, effectively breaking CAI. The attack can be mitigated by adding zero‑knowledge well‑formedness proofs, but this incurs quadratic time complexity in the number of options, making it impractical for large ballots.

In summary, the proposed PET‑based return‑code mechanism achieves a favorable trade‑off: low client overhead, strong distributed trust, and scalable server performance, while relying on standard cryptographic assumptions. Its main practical limitations are the need for a trusted printing channel and the lack of receipt‑freeness, which must be addressed through operational safeguards and possibly additional cryptographic enhancements for real‑world deployments.