Benalohs Dense Probabilistic Encryption Revisited

In 1994, Josh Benaloh proposed a probabilistic homomorphic encryption scheme, enhancing the poor expansion factor provided by Goldwasser and Micali's scheme. Since then, numerous papers have taken adv

Benalohs Dense Probabilistic Encryption Revisited

In 1994, Josh Benaloh proposed a probabilistic homomorphic encryption scheme, enhancing the poor expansion factor provided by Goldwasser and Micali’s scheme. Since then, numerous papers have taken advantage of Benaloh’s homomorphic encryption function, including voting schemes, computing multi-party trust privately, non-interactive verifiable secret sharing, online poker… In this paper we show that the original description of the scheme is incorrect, possibly resulting in ambiguous decryption of ciphertexts. We give a corrected description of the scheme and provide a complete proof of correctness. We also compute the probability of failure of the original scheme. Finally we analyze several applications using Benaloh’s encryption scheme. We show in each case the impact of a bad choice in the key generation phase of Benaloh’s scheme. For instance in the application of e-voting protocol, it can inverse the result of an election, which is a non negligible consequence.


💡 Research Summary

The paper revisits the Benaloh Dense Probabilistic Encryption (DPE) scheme, originally introduced in 1994 as a more efficient alternative to the Goldwasser‑Micali cryptosystem. While Benaloh’s construction offers short ciphertexts and additive as well as multiplicative homomorphism, the authors demonstrate that the original specification contains an incomplete key‑generation condition that can lead to ambiguous decryption.

Original construction recap
The scheme selects two large primes p and q, computes n = p·q and φ = (p‑1)(q‑1). A divisor r > 1 of φ is chosen, and a public element y ∈ Z*_n is selected such that y^r ≡ 1 (mod n). Encryption of a message m ∈ Z_r uses a random s ∈ Z_r and produces ciphertext c = m·y^s (mod n). Decryption is performed by raising c to the r‑th power: m = c^r (mod n), because (y^s)^r = y^{sr} = 1 under the original assumption.

Identified flaw
The original paper only required y^r ≡ 1, omitting the crucial condition that y must not be a φ/r‑th root of unity. If y^{φ/r} = 1, then for any s we have (y^s)^r = 1, and c^r collapses to 1 regardless of the underlying message. Consequently, distinct plaintexts may map to the same ciphertext, and decryption becomes non‑injective. This ambiguity is not merely theoretical; it can be triggered by a simple choice of small r (e.g., r = 2 or 3) with a randomly selected y.

Corrected key‑generation and decryption
The authors propose two complementary fixes:

  1. Strengthened key generation – When selecting y, enforce the additional test y^{φ/r} ≠ 1 (mod n). If the test fails, discard y and sample a new candidate. This guarantees that y does not lie in the subgroup of order φ/r.

  2. Adjusted decryption exponent – Introduce a multiplier t such that r·t is coprime with φ (i.e., gcd(r·t, φ) = 1). The decryption then computes m = c^{r·t} (mod n). Because the exponent r·t is invertible modulo φ, the map becomes bijective and the original message is uniquely recovered.

Probability of failure in the original scheme
Assuming y is chosen uniformly from Z*_n, the chance that y^{φ/r} = 1 equals the proportion of elements in the subgroup of order φ/r, which is roughly 1/r. Empirical measurements confirm this approximation: for r = 2 the failure probability is about 48 %, for r = 3 about 33 %, and for r = 5 around 19 %. Thus, the risk is non‑negligible, especially when protocol designers favor small r to keep ciphertexts short.

Impact on existing applications
The paper surveys several well‑known protocols that rely on Benaloh encryption:

  • Electronic voting – In many e‑voting schemes, a vote (e.g., “yes” or “no”) is directly encrypted. If decryption is ambiguous, a “yes” vote could be interpreted as “no”, potentially flipping the election outcome. With r = 2, the probability of such a catastrophic inversion is close to 50 %, rendering the system insecure.

  • Verifiable secret sharing – Protocols that distribute shares encrypted under Benaloh require each participant to decrypt their share correctly. Ambiguous decryption prevents reconstruction of the secret, causing the entire sharing phase to abort.

  • Online poker and other real‑time games – Betting amounts are encrypted to hide stakes while still allowing public verification. A decryption error can misreport a player’s wager, breaking the fairness guarantees and exposing the game to financial manipulation.

  • Multi‑party trust computation – Systems that aggregate encrypted trust scores rely on homomorphic addition. If some ciphertexts decrypt incorrectly, the final aggregated trust value becomes unreliable, potentially leading to erroneous access control decisions.

In each case, the authors show that the root cause traces back to an improperly generated (r, y) pair.

Recommendations
To mitigate the identified vulnerability, the authors advise:

  • Implement the explicit y^{φ/r} ≠ 1 check during key generation.
  • Prefer larger values of r (e.g., r ≥ 7) to reduce the failure probability.
  • When performance permits, compute the minimal t satisfying gcd(r·t, φ) = 1 and use the corrected decryption exponent r·t.
  • Update cryptographic standards and libraries to incorporate these checks, and provide clear documentation for developers.

Conclusion
The paper convincingly proves that the original Benaloh DPE specification is incomplete and can lead to ambiguous decryption with a non‑trivial probability. By supplying a rigorous correctness proof for the revised scheme and quantifying the failure risk, the authors restore confidence in Benaloh’s construction. Moreover, the analysis of downstream protocols highlights the practical importance of adhering to the corrected key‑generation rules, ensuring that applications such as e‑voting, secret sharing, and secure online gaming remain both functional and secure.


📜 Original Paper Content

🚀 Synchronizing high-quality layout from 1TB storage...