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.
It sounds like the technical problem is that they spent more time thinking about cryptography itself than they did about the prudent application of it.
Confidentiality that undermines availability might be good cryptography but it violates basic tenets of information security.
“Unfortunately, one of the three trustees has irretrievably lost their private key, an honest but unfortunate human mistake, and therefore cannot compute their decryption share. As a result, Helios is unable to complete the decryption process, and it is technically impossible for us to obtain or verify the final outcome of this election.”
⇒ that first paragraph is badly worded, but they’re not hiding facts.
I also think “3 out of 3” is not a good idea, as it allows any single key holder to prevent election outcomes that they don’t like (something that may have happened here, too. I don’t think cryptography experts often lose such keys by accident)
Their reasoning for not having 2 keyholder is that 2 people are more likley to colude to change the results (in this case announce false results) than 3. Of course 3 people could still colude to do so, so it's a matter of reducing not eliminating the risk.
My understanding is that in 2 out of 3, the third can also decrypt/view the results, so (assuming number 3 doesn't lose their key) then 2 can't colude to cheat (unless they also colude to somehow "deprive" number 3 of their key (e.g. with a heavy wrench)). If number 3 does lose their key, then the risk of colusion is higher than "requires all 3", but conversly the risk of "accidental or deliberate failed election" is lower.
It's (always) about a balance of risks.
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.
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.
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.
- 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.
22 comments
[ 1.9 ms ] story [ 49.9 ms ] threadHow 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
Confidentiality that undermines availability might be good cryptography but it violates basic tenets of information security.
The human half of the problem is the loss of the key; the technical half of the problem is being unable to decrypt the election results.
> The trustee responsible has resigned so why weaken security going forward?
I don't think there's a scenario in which a 2-of-3 threshold is a significant risk to IACR.
“Unfortunately, one of the three trustees has irretrievably lost their private key, an honest but unfortunate human mistake, and therefore cannot compute their decryption share. As a result, Helios is unable to complete the decryption process, and it is technically impossible for us to obtain or verify the final outcome of this election.”
⇒ that first paragraph is badly worded, but they’re not hiding facts.
I also think “3 out of 3” is not a good idea, as it allows any single key holder to prevent election outcomes that they don’t like (something that may have happened here, too. I don’t think cryptography experts often lose such keys by accident)
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.
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...
- 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.
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!?