Absolutely fascinating. I really want to know how they diagnosed this. Incredible.

How does the software revert make this better? Did they inadvertently remove some error correction?

This is one great example of how AI could be a huge accessibility win. I think we're all underestimating this category of use case.

Non, je ne suis pas d'accord, ce n'est pas la leçon a tirer. On peut échouer en faisant une election sur papier aussi. Les elections, c'est compliqué. Et avec Helios, l'association de cryptologues a réussi un niveau de confiance bien supérieur depuis 15ans.

You're sure you would never make a mistake here? Once in 15 years?

Yes, I agree, that could help!

lol yeah, that's one for the books.

Privacy in systems like Helios is always susceptible to collusion of (some of) the trustees, just a matter of deciding how large you want your minimum number of colluders to be.

Accuracy of the count, however, isn't affected even if all trustees collude.

We should totally fix this! Fewer rounds to set up effective threshold decryption would be amazing.

Best I can think of right now without actual threshold cryptography would be escrowing your share encrypted against one other trustee's public key.

Correct, Helios doesn't support this out of the box and it's the UX that would be awkward, not the cryptography.

IACR is going to move to 2-out-of-3 manually for now by sharing a key share across two trustees.

And then I gotta think about how to make this better, whether there is a reasonable UX.

so hard.

So the problem stands – how do you offer real security & privacy that different users can use safely? It's super hard.

All I can say is, if you're making fun of someone who lost their secret key, you're doing it wrong. It will happen to you someday, too.

And I need to make Helios better.

And still, to this day, about once every 2 months, a user clicks through the scary popup that tells them that if they don't save their secret key, they won't be able to tally their election. Then they lose their key and email asking for help. Help that is mathematically infeasible for me to provide.

I used to regularly get emails saying "I lost my private key, can you send me a new one?" But ... that doesn't work.

So I made the trustee function really scary. By default, Helios manages the key, and privacy is not as strong. There's an ugly scary popup if you try to set up trustees.

And of course this is where designing Helios for different audiences is really tricky. Some users, like the IACR, are super expert and they can go through the complex setup process. Other users don't even understand what a key is.

Do you require all trustees to be present for decryption, or do you tolerate a minority of trustees to be absent?

For resilience, it seems clear you should tolerate some trustees being absent. But that complicates the setup process: all trustees need to log in once, then a second time.

And then you need to manage how the decryption of the tally is performed, and the only way we know how to do that reasonably well is by having a set of trustees where no single individual can go rogue and break privacy.

But there's a very specific design tradeoff here.