Cryptographer and IACR member with a tiny bit of inside knowledge here.
To me, the entire matter is mostly amusing; the negative impact on IACR is pretty low. I now have to spend 10-15 minutes voting again. No big deal.
It saddens me that Moti Yung is stepping down from his position as an election trustee; in my opinion, this is unwarranted. We have been using Helios voting for some time; this was bound to happen at some point.
Don't forget that the IACR is not a large political body with a decent amount of staff; it's all overworked academics (in academia or corporate) administering IACR in their spare time. Many of them are likely having to review more Eurocrypt submissions than any human could reasonably manage right now. There are structural issues in cryptography, and this event might be a symptom of the structural pressure to work way more than any human should, which is pervasive not just in cryptography, but in all of science.
From what I heard on the grapevine, this scenario was discussed when Helios was adopted; people wanted threshold schemes to avoid this exact scenario from the start, but from the sources I can find, Helios does not support this, or at least it does not make threshold encryption easy. The book Real-World Electronic Voting (2016)[^0] mentions threshold encryption under "Helios Variants and Related Systems", and the original Helios paper (2008)[^1] mentions it as a future direction.
You don't have to tell these academics that usable security is important. Usable security is a vital and accepted aspect of academic cryptography, and pretty much everyone agrees that a system is only as secure as it is usable. The hard part is finding the resources—both financial and personnel-wise—to put this lesson into practice. Studying the security of cryptographic systems and building them are two vastly different skills. Building them is harder, and there are even fewer people doing this.
[^0]: Pereira, Olivier. "Internet voting with Helios." Real-World Electronic Voting. Auerbach Publications, 2016. 293-324, https://www.realworldevoting.com/files/Chapter11.pdf
[^1]: Adida, Ben. "Helios: Web-based Open-Audit Voting." USENIX security symposium. Vol. 17. 2008, https://www.usenix.org/legacy/event/sec08/tech/full_papers/a...
This seems a bit confusing and their documentation page was out of action when I tried it - why do the results need to be decrypted by trustees after the election? Is the concern that Helios itself isn't trustworthy to hold a key? And why do they need all trustees instead of a quorum of trustees by default? Not using a secret share for the real key seems like it is setting people up for this to happen and it sets up an odd dynamic where the more election trustees there are the less likely it is that the vote will be readable (in this case, if they'd only had one trustee they'd probably be in a position to read the results). In even a small group of people it is possible that one has a moderate-to-severe personal emergency in any week.
It'd be more robust in my opinion to have 4 mostly trustworthy people and a 3-in-4 secret share. That seems as good as 3 trusted people.
Cryptography is the science of turning any problem into a key management problem
Few lessons to relearn here:
- Availability is a security requirement. "Availability" of critical assets just as important as "Confidentiality". While this seems like a truism, it is not uncommon to come across system designs, or even NSA/NIST specifications/points-of-view, that contradict this principle.
- Security is more than cryptography. Most secure systems fail or get compromised, not due to cryptanalytic attacks, but due to implementation and OPSEC issues.
Lastly, I am disappointed that IACR is publicly framing the root cause as an "unfortunate human mistake", and thereby throwing a distinguished member of the community under the bus. This is a system design issue; no critical system should have 3 of 3 quorum requirement. Devices die. Backups fail. People quit. People forget. People die. Anyone who has worked with computers or people know that this is what they do sometimes.
IACR's system design should have accounted for this. I wish IACR took accountability for the system design failure. I am glad that IACR is addressing this "human mistake" by making a "system design change" to 2 of 3 quorum.
So what's it like between Cryptographers and secret keys? Is it like between Mathematicians and doing mental calculation of big numbers?
Why don’t they use password manager ?
Nerds do tend to forget that people make procedural errors.
Good.
Break your systems, identify the issues, fix it.
I want this to happen because I want mathematically secure elections.
That said… holy shit, you didnt think one of three groups could possibly lose a key due to human error!?
Oh man, I read "electron" and I thought this was quantum entanglement and cryptography :D
in other words, someone didnt like the election results
I'd make a joke about NSA conspiracies here but I'm 95% sure some kind of Foucault's Pendulum / QAnon thing would happen and 6 years from now I'd be the contrarian on a bunch of threads about how the IACR had been suborned to suppress cryptanalysis of MLKEM.
we have encountered a fatal technical problem that prevents us from concluding the election and accessing the final tally, [1]
How is someone losing their key a "technical problem"? Is that hard to own up and put the actual reason in the summary? It's not like they have stockholders to placate.
we will adopt a 2-out-of-3 threshold mechanism for the management of private keys [1]
The trustee responsible has resigned so why weaken security going forward?
I would have thought cryptography experts losing keys would be pretty rare, like a fire at a Sea Parks.
[1]: https://www.iacr.org/news/item/27138