Will my vote remain secret in 20 years? This is a natural question in the context of electronic voting, where encrypted votes may be published on a bulletin board for verifiability purposes, but the strength of the encryption is eroded with the passage of time. The question has been addressed through a property referred to as everlasting privacy. Perfect everlasting privacy may be difficult or even impossible to achieve, in particular in remote electronic elections. In this paper, we propose a definition of practical everlasting privacy. The key idea is that in the future, an attacker will be more powerful in terms of computation (he may be able to break the cryptography) but less powerful in terms of the data he can operate on (transactions between a vote client and the vote server may not have been stored).

We formalize our definition of everlasting privacy in the applied pi-calculus. We provide the means to characterize what an attacker can break in the future in several cases. In particular, we model this for perfectly hiding and computationally binding primitives (or the converse), such as Pedersen commitments, and for symmetric and asymmetric encryption primitives. We adapt existing tools, in order to allow us to automatically prove everlasting privacy. As an illustration, we show that several variants of Helios (including Helios with Pedersen commitments) and a protocol by Moran and Naor achieve practical everlasting privacy, using the ProVerif and the AKisS tools.


The protocol verifier ProVerif has been modified to support the following declarations:

  • in phase p1,...,pn reduc g(M1,...,Mn) = M.

    The given reduction is only made available (to the process and the attacker) in the specified phases.

  • in phase p1,...,pn equation M = N.

    The given equation is only made available in the specified phases.

  • future phase p with channel M1,...,Mn.

    Phase number p is considered to be in the future. In this phase, messages previously sent on channels M1 to Mn are available to the attacker, but messages from other channels in previous phases are not.

A patch for ProVerif 1.86pl4 is available here, which can be applied with patch -p1 < ProVerif_ev.diff.

ProVerif_ev scripts for the case studies