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.
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.
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.
Even if this was an accident, isn't it theoretically possible for one of the trustees to intentionally not provide the key to trigger the re-election? There's no guarantee that the people will vote the same. I see this as a kind of vulnerability.
The opposite is interesting to think about - for a commonly used threshold cipher, could you craft your part to secretly force a chosen plaintext regardless of the other parts?
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.
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
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.
> spent more time thinking about cryptography itself than they did about the prudent application
"Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should"
> How is someone losing their key a "technical problem"?
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.
There's physical loss and data loss as well. Key storage devices are not perfect. You even have to account for HSM failures.
I believe the DNSSEC uses a 5 of 7 approach.
Thanks for the reminder of a brilliant IT crowd moment!
https://archive.is/NOnfx
Nerds do tend to forget that people make procedural errors.
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.
in other words, someone didnt like the election results
Don't know why your comment is downvoted so much.
Even if this was an accident, isn't it theoretically possible for one of the trustees to intentionally not provide the key to trigger the re-election? There's no guarantee that the people will vote the same. I see this as a kind of vulnerability.
They wouldnt know the result before providing the key.
The opposite is interesting to think about - for a commonly used threshold cipher, could you craft your part to secretly force a chosen plaintext regardless of the other parts?
"When you definitely know what an IACR director does."