The International Association for Cryptologic Research (IACR) has annulled the results of its annual elections after losing a critical component of the cryptographic key required to decrypt the final tally in the Helios electronic voting system. The incident highlights how even world‑class cryptographers can be undermined by weaknesses in cryptographic key management and operational procedures.
How IACR Used Helios for Cryptographically Secure Elections
IACR is a leading global body for researchers in cryptography and information security. In line with its mission, the association conducts its internal elections using Helios, an open source, end-to-end verifiable electronic voting system based on peer‑reviewed cryptographic protocols rather than conventional web polls.
In Helios, each ballot is encrypted before it is cast. Ballot secrecy is preserved, while each voter can verify that their encrypted vote was included unmodified in the final tally. All ciphertexts are published, and the correctness of the tally is proven mathematically using public, verifiable cryptographic proofs, reducing the need to trust any single administrator or server.
Threshold Cryptographic Keys and the Role of Trustees
Under the IACR bylaws, elections are overseen by a committee of three independent trustees. To avoid concentrating power in one person, IACR uses threshold cryptography: instead of one decryption key, the private key is split into several key shares, each held by a different trustee.
For this election, IACR used a strict “3-of-3” threshold scheme. All three key shares were required to jointly decrypt the final election tally. As long as one share was missing, decryption was technically impossible, which is exactly what occurred.
Why the 3-of-3 Model Failed in Practice
One of the three trustees irretrievably lost their private key share. According to IACR’s statement, there is no indication of malicious intent; the loss is attributed to human error. However, in a 3-of-3 configuration, the loss of a single share is equivalent to destroying the entire private key.
This is not a failure of the Helios voting system or the underlying cryptography. Helios behaved as designed: it refused to decrypt the tally without the full set of required key shares. The failure lay in key management policy design—specifically, choosing a threshold that maximized resistance to collusion but left no tolerance for operational mistakes.
Key Management, Human Error and Security Controls
The incident underscores a longstanding reality in cybersecurity: even robust cryptographic protocols can be undermined by organizational and human factors. Industry data supports this; for example, the Verizon 2023 Data Breach Investigations Report found that around three-quarters of breaches involve a human element, such as misconfigurations, mistakes or social engineering.
In corporate environments, Public Key Infrastructure (PKI), Hardware Security Modules (HSMs) and secret sharing schemes are only as strong as the processes for storage, backup and rotation of keys. Best practices, reflected in guidance such as NIST SP 800‑57, typically include:
- Using “m-of-n” threshold schemes (e.g., 2-of-3, 3-of-5) to tolerate the loss of one or more key shares while still preventing unilateral misuse.
- Storing keys or key shares in HSMs or other tamper‑resistant devices, rather than on unmanaged personal devices.
- Implementing documented backup and recovery procedures and periodically testing that key material can in fact be restored when needed.
- Enforcing role separation, dual control and independent audit for operations involving cryptographic keys.
IACR’s Response: New Elections and a 2‑of‑3 Threshold
Once it became clear that the missing key share could not be recovered, IACR formally acknowledged that the election results could not be decrypted. The organization announced that it will hold new elections, with the new voting period running until 20 December 2025.
At the same time, IACR decided to change its key management policy for future election cycles. Instead of requiring all three trustees, the system will move to a “2-of-3” threshold, allowing any two trustees to jointly decrypt the tally. This maintains protection against unilateral abuse while significantly reducing the risk that a single key loss will block the entire election.
One of the trustees, Moti Yung, whose key share was lost, resigned from his role. This step highlights the community’s recognition that operational security (OpSec) around keys is as critical as protocol design in high‑assurance systems such as electronic voting.
Key Lessons for Electronic Voting Security
The IACR–Helios case is instructive far beyond the academic cryptography community. It illustrates that electronic voting security is not determined solely by algorithm strength, but by how cryptography is embedded into governance, processes and human workflows.
Architects of e‑voting systems and security practitioners can extract several concrete lessons:
- Balance collusion resistance with fault tolerance. Thresholds for decryption keys should protect against insider collusion without making systems brittle in the face of inevitable human error.
- Design, document and rehearse recovery procedures. Key recovery, trustee replacement and incident‑response playbooks must be tested in advance, not written after a failure.
- Train trustees and key custodians. Non‑technical or semi‑technical stakeholders need clear guidance on secure key storage, backup and device hygiene.
- Treat cryptography as part of a system, not a magic shield. Protocols, infrastructure, people and policies must all be engineered and audited as a single security system.
The IACR incident is a rare public example of how even a highly expert organization can be disrupted by a key management failure. For governments, enterprises and developers of electronic voting platforms, it is a prompt to re‑evaluate key policies, verify backup mechanisms and ensure that the loss of a single device or share cannot paralyze critical democratic or business processes.
