Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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"


A few paragraphs down, they say:

“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)


> 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's also important to factor in the case of "a key holder was hit by a bus, and now we can no longer access their private key".


I’m fairly sure the holder of a single private key cannot see the outcome of the election, then withhold the key if they don’t like it. Of course, if they reasons outside the narrow election process (media, gossip) to believe that the outcome would be unfavourable to them, then that’s a reasonable worry.


Maybe when the next draft of democracy is written it can leverage these tools.


> 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.


Earlier in the article they explain why only 2 keyholders is a bad idea, then the final statement is they are going to do that anyways.


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.


2 out of 3 is arguably more secure. availability is important.


Thanks for the reminder of a brilliant IT crowd moment!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: